MVC, MVVM, ReactorKitで構築できるThe Reactive Architecture(Reactive Programming + Flux)について iPhone Dev Sapporo勉強会 May, 2017 https://devsap.connpass.com/ev…
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? iOS関係の勉強会に参加するとほぼ間違いなく、設計に関する発表があるように思います。 「RxSwiftを使ってMVVM...」「Clean Architectureを導入...」, etc... 色々話を聞く中で、自分は以下のような課題があるなぁと感じています。 いろいろな設計方法があるけれど、結局何を使うべきなのかわからない 名前は聞いたことがあるけれど、それぞれがどのような設計で、何がメリットなのかわからない 勉強した時は分かったような気がしたけれど、もう忘れた この記事はこれらの解決の一助になればと思って書いたものになります。(設
本記事は QiitaAdventCalender2016の「iOS その3 Advent Calendar 2016」の12月4日の記事です。 また、本資料の「VIPERの使い方」は iOS Project Architecture: Using VIPER の翻訳資料です その後に続くのはオリジナルの文章です。 本記事の一部は原文をもとに翻訳をしていますが、一部翻訳が難しい箇所は違和感を持たぬ日本語への意訳となっています。 誤訳していたら教えてください。 VIPERの使い方 ※ 画像は原文から引用 iOSアプリを開発するとき、iOSプロジェクトアーキテクチャを何を使うか考えるのはとても重要です。 もっとも使われているApple推奨パターンは、MVCアーキテクチャと呼ばれているものです。 しかし、実際定着してるMVCには欠点があります。 その欠点の1つはシンプルさのせいで、経験豊富なエンジ
<この記事は「Money Forward Advent Calendar 2015」の22日目の記事です> この記事は、iOS Clean Architectureと実際にコードへ適用した内容について紹介します。 コードについては、改善の余地があるため随時修正していくと思います。 → github: https://github.com/koutalou/iOS-CleanArchitecture iOS開発においてよくある問題点 「ビジネスロジックはModelに置くべき」と言うが、開発者によって理解や意見がバラバラで統一的な実装ができない 度重なる仕様変更や複雑な仕様に対応するためにViewControllerや特定のModelが肥大化し、ビジネスロジックの本質を見失う MVC,MVP,MVVMだけで考えると、どこかのレイヤが複数の責務を持つことになり依存度の高い複雑なコードが生まれてし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く