MVPどうもおはようございます、こんにちは、こんばんは。今回は、アーキテクチャをまとめてみました。スキルセットの考慮プロジェクトの期間と規模プロジェクトの優先項目アーキテクチャ変更によるリスクまとめアーキテクチャを取り入れる理由アーキテクチャはアプリを綺麗に開発・継続的に運用していくための設計方法。UI(プレゼンテーション)とそれ以外のUIに関連しない処理(ドメイン)にざっくり分けられる。分けられると何が良いのか。これによって、品質や開発スピードの向上につながる。アーキテクチャによって特徴が異なるため、開発人数や環境、期間などによってどれが最適か検討する必要がある。Appleが推奨しているアーキテクチャ。CocoaMVCの大きな特徴は、ViewとModelが完全に独立しているところ。ModelとViewが独立していることによって、再利用性が高まり、Controllerだけ作り直せば流用できる。開発スピードが早い、シンプルな構成で学習コストが低い。経験が浅くても保守しやすい。Modelのテストが可能になる。ViewControllerの肥大化や重複コードにより可読性の低下。特徴はテスト容易性と作業分担のしやすさを実現させるところ。フロー同期(対象データを更新してからUI更新する)のためデータフローが追いやすく書き易い。化して疎結合にすることで、Presenter単体でのテストが行える。MVVMやCleanArchTectureなどに比べるとシンプルな構成。View(viewController)の肥大化が抑えられ可読性が向上する。画面ごとに書き方が統一しやすい。MVCに比べると学習が必要。特徴はViewとViewModelをデータバインディングと呼ばれるしくみで関連付けることで、ViewModelの状態を更新するだけで、Viewの状態も更新され画面に反映される。ネットを見ていると最近よく使われているパターンの一つ。Viewへの更新通知、指示の部部分のコードが不要。小規模、少人数のプロジェクトではコストに対してリターンが少ない。サーバー通信や例外処理などもModelに切り分けられることが多いが、より責務を細分化して定義することで変更に強く可読性が高い。各層を単一方向につなげる。OSに非依存のロジックはAndroid,iOSで同じように書きやすい。責務を細分化するためファイル数が多くなる。各アーキテクチャを比較検討した結果、MVCのまま実装するのが良いと考えた。「何をどこに置く」という規約として機能し、コードの粒度を揃える機能がある。ようなある程度自由の効くアーキテクチャパターンが良いと感じた。プロジェクトの期間と規模MVVM,CleanArchtecureは、スタートアップで根本的な概念、仕様の見直しが発生するプロジェクトでは効果が出づらくMVCやMVPのような最低限のパターンでの方が、今回のプロジェクトの場合レビュワーの負担の減少や開発スピードという点で良い。向けてはテストの容易性なども必要になってくるとは思うが開発、保守のしやすさなどからMVCで問題ないと感じる。アーキテクチャ変更によるリスク現状一定の品質を担保しながら開発スピードを上げるためMVCを採用している。変更のバックログを作成し期間を確保すれば問題ないが、今後開発人数が増えないことや上記の理由などからリスクを取る必要のある恩恵がないと判断される。MVCを採用してますが、現在技術検証ということでMVPの反映とかやっているのでまた実際に実装した所感も書ければと思います。ブログの投稿は基本毎日19時頃する予定です。part1〜デザインテーマ、設計原則〜検索はてなブログをはじめよう!chiltarou1224さんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。