3層アーキテクチャのASP.NETアプリがあります。
プレゼンテーション層：ASP.NET
Bussiness Layer：C＃ライブラリ。
データアクセス層： ADO.Net Entity Frameworkオブジェクトを含むC＃ライブラリ。
Bussinessレイヤーの一部のメソッドはADO.NETエンティティオブジェクトを返しますが、データアクセスレイヤーはプレゼンテーションレイヤーに表示されません。それはできません。
私の質問は次のとおりです。デザインビューで、プレゼンテーション層でエンティティオブジェクトを公開するのは正しいですか？データレイヤーライブラリをASP.NETアプリにリンクするだけでよいと思います。
ありがとうございました！
エンティティオブジェクトをプレゼンテーション層で使用および使用できるようにすることが絶対に望ましいです。それがすべての仕事の目的です。
これはあなたの人生をはるかに楽にします。それ以外の場合は、プレゼンテーションレイヤーとビジネスレイヤーの間で、文字列の後に文字列を渡す必要があります。
これらは、エンティティオブジェクト、またはエンティティオブジェクトからハイドレイトされた独自のPOCOオブジェクトである可能性があります。
私は、あなたのエンティティは、DALとは別の独自のアセンブリにあるべきだとさえ言っています。
いいえ、そうではないと思います。データクラスを動作から分離し、プレゼンテーションレベルでデータクラスのみを参照するのが最善の方法です。WCFを使用するための良いアプローチは、このリンクを参照してください。
ビュー オブジェクト...またはデータ転送オブジェクト (DTO) の概念を調べることをお勧めします。エンティティからビュー固有のドメイン オブジェクトを作成する AutoMapper などのツールの使用を検討することもできます。一般に、作業を実行するためにエンティティの存在が必要な画面がある場合があります。しかし、多くの場合、いくつかの異なるエンティティを渡す必要があります。この場合、これらすべてのエンティティを含む 1 つの DTO を作成する方が適切です。これにより、プレゼンテーション層とビジネス層の間に分離層が追加されます。多くの場合、エンティティには、プレゼンテーション レイヤーに公開したい機能よりも強力な機能があります。およびその逆。ビジネス レイヤーでフラグが立てられた検証に基づいて、UI メッセージをプレゼンテーション レイヤーに送信する必要がある場合がよくあります。UI を必要以上に複雑にする (エンティティ全体を渡す) のではなく、UI が必要とするものだけを DTO の形式で渡すことができます。また、ビジネス オブジェクトがプレゼンテーション層に固有のものを気にする必要はまったくありません。データアクセスレイヤーまでさかのぼって直接データバインドしないことをお勧めします。技術的には、プレゼンテーション レイヤーは、ビジネス レイヤーについて可能な限り知識を持たないようにする必要があります。MVP または MVC の場合、この追加の分離によってフロントエンドとバックエンドを切断することで、これを非常に簡単に実現できます。データアクセスレイヤーまでさかのぼって直接データバインドしないことをお勧めします。技術的には、プレゼンテーション レイヤーは、ビジネス レイヤーについて可能な限り知識を持たないようにする必要があります。MVP または MVC の場合、この追加の分離によってフロントエンドとバックエンドを切断することで、これを非常に簡単に実現できます。データアクセスレイヤーまでさかのぼって直接データバインドしないことをお勧めします。技術的には、プレゼンテーション レイヤーは、ビジネス レイヤーについて可能な限り知識を持たないようにする必要があります。MVP または MVC の場合、この追加の分離によってフロントエンドとバックエンドを切断することで、これを非常に簡単に実現できます。
Entity を渡すと、基本的にはコントローラーの監督になります。それ以外の場合は、パッシブ ビューです。
コントローラーの監視は手間がかかりませんが、テストしにくくなります。監視コントローラーも、データバインディングは問題ないと言っています。パッシブ ビューはテスト可能ですが、さらに多くの作業が必要です。データバインディングなし。プロパティがたくさん。
通常、私は監視コントローラーに固執します。通常、そのレベルのテスト可能性は必要なく、余分な手間をかける価値はありません。