MVPでは、データモデルの複雑さはどのように処理され、どこでコントロールを動的に表示/非表示するのですか？

Question

私が見たMVPの例のほとんどで、プレゼンターはエンティティを返すリポジトリを呼び出すサービスを呼び出します。私が取り組んできたほとんどのasp.net Webアプリケーションでは、ロジックは決して簡単ではありません。私の最後のプロジェクトでは、私の発表者は、画面に表示されるデータを取得するためにフープを飛ばしなければならなかったプレゼンターサービスレイヤーを呼び出しました。

詳細：サービスレイヤーは、8つのエンティティオブジェクト（その中のいくつかは相互に入れ子になっています）をデータベースに照会し、それらのエンティティをXSDの1つの巨大なオブジェクトベースにマッピングします。そのxsdオブジェクトは、それを使って何かを行うために第三者図書館に渡されました。処理されたxsd objが返された後、コードは中間層ビューフォーマッタクラスを使用してその「xsd」オブジェクトを解析し、「モデルの表示」と呼ばれるものを抽出してビルドしなければなりませんでした。このViewモデルは、サービスレイヤからプレゼンタに返された後、リピータにバインドされたデータです。

1. 表示/非表示制御のロジックはどこにありますか？それはDTOのメンバーか、またはプレゼンターがこの値を引き出すべきか？ （ビューモデルのメンバとして持っていました）
2. ネストされたViewModel（DTO）を持っていても構いませんか、他のユーザコントロールを使って複雑さを解消する必要がありますか？
3. プレゼンターを使用するすべてのページ/ユーザーコントロールにプレゼンターを接続するにはどうすればよいですか。プレゼンターの同じインスタンスを必要とする5つのIViewsを持つ1つのプレゼンターを意味します。ユーザコントロールは自己完結型であるべきか、適切なプレゼンターを与えるために「親」IView（ページ）に依存すべきか？

4. ページが実装するインターフェイスを使用してそれをサービスレイヤーに渡すだけで（プレゼンターから）、サービスがIViewを水和させるのはなぜですか？ （これを行うと、サービス層に参照があるようになりますが、それは悪いことではありません）。

   public class ViewModel 
   { 
       public bool ShowHeight { get; set; } 
       //Is there a bettter way to do this? 
       public List<NestedViewModel> NestedViewModel { get { return _nestedViewModel; } } 
   } 
   

Answer 1

1. IMO、ビューは、表示と非表示に自分自身を管理するべきです。ビューであり、UIの動作を管理します。
2. 私は、あまりにも威圧的でない限り、複雑さは問題ないと思います。必要に応じてネストされたサブプレゼンター/ビューに分割することができます。
3. ほとんどのMVPフレームワークは、特にASP.NETがページのコンテキストで実行されるため、ビューからプレゼンター/ビューのリレーションシップを読み込みます（ページは要求を処理するHTTPハンドラーであるため、その時点で有効です）。 initの間のページは、ビューとプレゼンターの関係になります。ほとんどの例がこのようにしています。私はMVPフレームワークを構築し、このアプローチを確立しました。
4. できます。プレゼンターは依然として作業を行い、サービスレイヤーに直接渡すべきではありませんが、それはパッシブビューと見なされます。

これは私の意見であり、これを行う方法はたくさんあります。