アーキテクチャ設計の目的は、開発の複雑さを管理し、プロジェクト内のロジックを合理的に分割し、プロジェクトの保守と管理を容易にして、開発時間を節約し、開発効率を向上させることです。
現在、実際の開発プロセスで一般的な集中型アーキテクチャとしては、主に MVC、MVVM、VIPER (View Interactor Presenter Entity Router) が挙げられますが、これらのアーキテクチャの設計思想は基本的に同じであり、後者は MVC をベースとしたロジックとなっています。分けられますが、程度も方法も異なります。
まずは Apple が公式に推奨している設計手法である MVC について、主に Model、View、Controller について簡単に紹介します。
Model：封装的数据模型，用来保存数据；
View：视图控件，用来展示视图；
Controller：主要是视图控制器，用来处理用户事件，更新视图和数据等逻辑；
その設計思想は、ビューとモードの間の結合を減らすことです。ビューにはビューのみが含まれ、モデルにはデータのみが含まれ、コントローラーは 2 つの間の論理関係を制御するために使用されます。ビューとモデルを直接接続する必要はありません。ただし、この設計パターンはプロジェクトの複雑さに伴って徐々に増加し、コントローラー コードの肥大化、管理の不便さ、メンテナンス コストの増加などの問題が顕在化します。
Controller の負担を軽減するために、View の表示データを統合するロジックを抽出して ViewModel にカプセル化する MVVM 設計手法があり、主に次の 3 つの部分で構成されます。
Model：此处的Model与MVC中的Model相同，是封装的数据模型；
View：此处的View是指的的View和ViewController，用于展示视图和接收用户事件等；
ViewModel：视图模型有直接用于展示的接口和数据输入接口，其主要作用是，将初始数据处理成为直接用于视图展示的Model；
MVVM では、双方向バインディング (データおよびユーザー アクション バインディング) を使用して View と ViewModel の状態を同期します。ビューの変更は、バインドされた ViewModel に自動的に反映され、その逆も同様です。設計上の考え方は、MVP に基づいてコントローラーからビューの表示を担当するデータ処理ロジックを抽出して、ViewModel を形成することです。
MVVM の 3 つの要素間の論理関係は次のとおりです。
1. Model データが ViewModel に提供され、ViewModel によって処理されて、View が直接表示できるデータに変換され、その後 ViewMode の状態が更新されます; 2. View レイヤーがユーザー イベントまたは状態変更イベントを受け取ると
、ビューにバインドされた ViewModel も同期的に更新でき、その後 ViewModel は対応するローカル モデル データを更新します。
MVVM の利点は次のとおりです:
1. 結合度が低く、ビュー ロジック処理と他のビジネス ロジックの間の結合が軽減されます;
2. 再利用性、共通のビュー ロジックが ViewModel にカプセル化され、多くのビューでこのビュー ロジックを再利用できます
。ビューの単体テストに便利です。ビュー ロジックが分割されているため、対応するビューまたはスタイルをテストする場合、ViewModel 内のビュー ロジックを変更するだけでよく、他のビジネス ロジックとは何の関係もありません。
プロジェクト システムの複雑さが増すにつれて、メンテナンスを容易にするために、より詳細な要件を抽象化し、個別に処理する必要があります。コントローラー内のユーザー インタラクション ロジックとルーターの責任は、コーディネーター (プレゼンター) によって分割され、スケジュールされるため、VIPER (ビュー インタラクター プレゼンター)エンティティルーター) アーキテクチャ。
VIPER アーキテクチャ設計は主に 5 つの部分に分かれています。
1、View：指View与ViewController，包含UI层面的业务逻辑以及交互层面的接口调用和转发；
2、Interacter：交互器，包括用户交互动作和关于数据和网络请求的业务逻辑，例如创建一个实体（数据），或者从服务器中获取一些数据。
3、Presenter：统一调用各个部分之间的协议接口，例如将Interacter中请求来的数据传递给View层，将用户交互事件传递给路由层等；
4、Entity：实体模型，普通的数据对象；
5、Router:用于各个页面层次之间的联系绑定，页面视图跳转链接等；
主な設計アイデアは、MVC のコントローラーからビジネス ロジックを抽出することです。
VIPER アーキテクチャは、View、Interactor、Router などのロジックを抽象化します。これを使用する場合、まずさまざまな論理抽象化を対応するプロトコルにカプセル化し、次にビュー コントローラーのプロトコルを通じて、さまざまな論理処理が Presenter オブジェクトに引き渡されます。Presenter オブジェクトはすべてのプロトコルに従い、対応する関係をバインドして統一処理します。その中で、Router ロジックは多くのオープンソース ライブラリによってカプセル化されており、 JLRoutes、HHRouter、MGJRouterなどを呼び出すのがより便利です。
上記の設計パターンにはどれが優れているというものはなく、プロジェクトの実情に合ったものだけが最適です。上記のアーキテクチャ設計パターンは学ぶ価値のある設計アイデアであり、特定の設計パターンをコピーしただけでは、ほとんどの場合、プロジェクトの問題は解決されません。プロジェクトを良好な状態に維持するには、通常の開発プロセス中に、対応するビジネス コンポーネントをタイムリーに要約および抽象化し、プロジェクトをスリム化してプロジェクトの再利用性と拡張性を向上させる必要があります。構造設計の欠陥が発見された場合は、「タールピット」を避けるために調整手順を迅速に計画する必要があります。