【Unity】UIのMVPフレームワークの理解、フレームワークの話

フレームワークのインポート

フレームワークとは
多くのコースでは、いわゆるフレームワークについて言及します。インターンシップに参加する前は、構築の基礎として特定のコンポーネントやその他のものが必要になる可能性がある非常に大きな環境であると常に感じていました。
実際に連絡を取ってから、実は、いわゆるフレームワークは主に開発仕様として存在します。、その実装は必ずしも何にも依存しません。

なぜフレームワークが存在するのか?
大規模なプロジェクトの実際の開発では、通常、プロジェクトには数十人が一緒に取り組んでいます。特にバグ修正の日々では、1 日に数百件、1 日に数十件の修正記録が提出されることもありますが、これは通常のことです。明らかに、誰もが異なる習慣、異なる言語経験、およびコードに対する異なる考え方を持っているため、自然にさまざまな奇妙な方法で記述します。このようなシステムは、可読性に欠ける傾向があります。プロジェクトのメンバーは、他の人が奇妙な方法で何かを導入または削除したため、自分のコードを認識できないことさえあります。言うまでもなく、多くの人がコメントを書くことができますよね。

この時、フレームワークの重要性が反映されます。特定の機能に応じてコードを分割することで、一部の複雑な構造が一定の方法で整理され、ターミナルはとにかく一部の特定の機能のみを実現し、プロジェクト全体の可読性が質的に向上します。

次に例です
Unity には、デリゲート、イベント、およびアクションで構成されるオブザーバー パターンがあることは誰もが知っています。ただし、特定の場所でイベントを開催する人もいれば、1 つのイベントを 1 つのイベントとして考える人もいます。その後、さまざまなイベントやコードがさまざまな機能段階で再利用され、プロジェクトは徐々に結び目になり、最終的にいわゆるShishanコードが確実に現れます。
では、それぞれの大きな関数には複数のコンポーネントがあることを規定し、イベントを使用する必要がある場合は、新しい固定イベント スクリプトを作成します。最終的に、スクリプトは膨大な量になりますが、読みやすさは大幅に向上しました。
主要な機能ごとに異なる機能を分類し、同じ特性を持ついくつかのコードでイベントを統合すると、スクリプトの数が削減されます. 同時に、一定の構造を規定し、各スクリプトは固定された機能と構造に従って分割されます.スクリプトの数を減らしながら、コードは非常に読みやすくなります。

MVP フレームワークについて簡単に説明します

フレームワーク

いわゆる MVP フレームワークは、Model-View-Presenter です。
つまり、モデル ビュー ロジック レイヤーです (標準名ではありません)。
1. モデル層
この層は、主に外部バイナリ ファイル、json ファイル、テキスト ファイルなどのデータを担当します。プロジェクトの特定のニーズに応じて、固定形式のデータと接続するための定義と、データ モデルとしてのモデル レイヤーに分割できます。次に、モデルを初期化するためのデータ クラスを作成できます。
2. ビュー レイヤー
このレイヤーは当然ビュー部分を担当します. MVP フレームワークは主に UI フレームワークであるため、この部分は主に UI であり、画像、テキスト、およびページの他の部分を含みます. 要件に応じて、外部から Page によって呼び出される初期化 UI、単一のページとして存在する Window、および複数の連続したウィンドウを持つ Param に分割されることがよくあります。
3. プレゼンター層
この層はシンプルでシンプルですが、複雑でもあります。単純さは、一般にプレゼンターのみが存在することであり、複雑さは、このレイヤーがすべてのロジックを処理することです。たとえば、ビュー レイヤーのボタン イベント登録は、プレゼンター レイヤーがイベント ロジックの実装と登録を実行するまで、継続的に呼び出す必要があります。
4. その他に利用できるもの
ウェアハウス Regestroy を知っています. データ量が多い場合、または他の適切なデータ ストレージが確立されている場合、ウェアハウスが初期化され、データ アクセスが容易になります。

フレームワーク プロセス

一般的に言えば、ページが外部呼び出しによって開かれると、主にページに対応する機能を持つプレゼンターが存在します。プレゼンターは、ターゲット プレハブの生成、データに基づく対応するモデルの生成、必要に応じてウェアハウスへの格納など、ターゲット関数のウィンドウの初期化を担当します。次に、さまざまなコンポーネントのイベントを登録します (存在する場合)。dispose メソッドを作成し、その中のコンポーネントの dispose メソッドを呼び出します。UpdateView メソッドを作成して、生成を繰り返さずにコンポーネントの再利用を実現します。UpdateView メソッドで子ウィンドウごとに UpdateView を呼び出します。
When a component of the View layer is triggered, such as a button or Scroll event, it will be passed to the Presenter layer, and the Presenter layer will logically process the event. データが必要な場合は、ウェアハウスから取得されるか、または既に保持されているデータリストを取得します。このイベントが新しいページを開く場合、新しいページを生成する Page が呼び出され、Page は次の Presenter を生成し、現在の Page を前の Page として使用します。(ここのページは、リンクされたリストのようなものです。最後のページが常に開かれます。ページが閉じられた場合、前のページが開かれます。このプロセスは、異なる機能間の切り替えです。同じサブに属している場合大きな関数の関数、それを考慮する必要があります.それはPageの形ですか、それともParamの形ですか）

最後の思い

この MVP フレームワークは、実際には特に完全ではありません。マルチレイヤー処理が必要になる場合があり、1 レイヤーのプレゼンターでは必要なことができない場合があるためです。しかし、ほとんどの場合、この構造はそれに対処するための良い方法です。Viewレイヤーもあります.理論的にはすべてのロジックはPresenterレイヤーに帰属するはずですが、ちょっとした小さな機能のためにそんなに大きな動きをする必要はないという怠惰な人もいます.関数はまだ Presenter 層にあり、より複雑になりますが、各関数の構造はよりきちんとしています。