多層アプリケーションのビューを扱う方法

Question

私は、基本的に3つのレイヤーを持つプロジェクト、すなわちプレゼンテーション、ビジネス、データを扱っています。 各レイヤーは異なるプロジェクトにあり、すべてのレイヤーは別のプロジェクトで定義されたDTOを使用します。 ビジネス層とデータ層は、データベースを照会するときにDTOまたはDTOのリストを返します。

これまでのところよくできていましたが、今はビューをクエリする必要があり、もちろんこれらのビューは既存のDTOと一致しません。今まで私たちが行ってきたことは、特別なDTOクラス、ビジネスクラス、データレイヤクラスを作成して、通常のエンティティ（挿入、更新などを除く）と同様に扱うようにすることです。

しかし、彼らが明らかにそうでないときには、なぜ通常のエンティティのように扱われるべきですか？まあ、DTOは必要だと思われますが、すべてのビューに対して "ビジネスロジック"とデータレイヤークラスを作成するのはむしろ難しいようです。だから私は、すべてのビューのロジック/コードを保持する一般的なビジネスクラスとデータレイヤーのクラスを作成すると考えました（おそらく、私は別のビューごとにDTOを作成しなければならないかもしれません）。あなたはこの問題をどのように解決しますか？

編集：9. 2011年8月 申し訳ございませんが、投稿が不明瞭になっている可能性があります。 ビューで私はSQLサーバーからのビューを意味します。

Answer 1

レイヤ間でDTOを使用しないことをお勧めします。何か有益だと私は確信していませんが、もしあなたが何かを持っていると思うなら、教えを受けて喜んでします。

同じ考えを表現する複数の並列階層（ビジネスオブジェクトと複数のレイヤー間の複数のDTO）を維持することには害があります。これは、多くのコードを維持し、より大きなエラーの可能性を意味します。ここで

は、私がアプリケーション層と思います方法は次のとおりです。

view <--- controller <--- service <--- + <--- model 
             + <--- persistence 

この設計は、サービスからの景色を分離します。さまざまなビューでサービスを再利用できます。サービス・メソッドは、ユース・ケースを実装し、ビジネス・ルール、自分の作業単位およびトランザクションに従って入力を検証し、モデルおよび永続オブジェクトと協力して要求を実行します。

コントローラとビューは緊密に結合されています。ビューを変更し、コントローラを変更します。ビューは、コントローラによって提供されるデータをレンダリングする以外は何もしません。コントローラは、検証、バインド、適切なサービスの選択、応答データの利用、次のビューへのルーティングを行います。

ロギング、トランザクション、セキュリティなどのクロスカッティングに関する問題は、適切な層（通常はサービス）に適用されます。

サービスと永続性は、インターフェイスベースである必要があります。

Answer 2

私はあなたの痛みを完全に感じます。事実、まったく重要でない複雑なプロジェクトでは、UI上でユーザーに提示しなければならないことが、ビジネスエンティティのデータの一部であるか、集約されているかということになります。私がこれに近づく傾向は、この事実を受け入れてさらに進んでいくことです。クエリ側をビジネスロジック側から論理的および物理的に分離します。事実、実際の事業運営にのみエンティティを必要とし、ビジネス制約を有効に保つ必要があります。これはいつ起こりますか？誰かがデータを変更したときのみ。したがって、データを表示するときにエンティティを作成する必要はありません。私は解決策を構築したいと 方法は次のとおりです。

ユーザーは、ビューを開く - >照会のみのビューのために特定の データを取得するために実行される - >返されるデータは、モデルである（あなたが それを呼び出すことができますが、同様DTO、この場合には、それは同じことだ）

ユーザーが何か変わる - >コントローラー（またはサービス）はレポから完全なエンティティを構築し、 ビジネス・ロジック・アクションは、エンティティ上で実行される - >変更は 保持されます - >結果が返されます

私が言いたいのは、書き込み側とは別に読み取り側を扱うことは大丈夫です。このために別のインフラストラクチャを持つこともOKです。別の方法で処理すると、メリットが表示されます。たとえば、UIに必要なものをクエリに合わせることができます。 インフラストラクチャが、LINQや一般的なSQLクエリなどのさまざまな手法を使用してクエリを構築できるようになることもあります。これは特定のシナリオに最適です。

Answer 3

私はすべての変換を管理するのに苦痛であり、過度に複雑であるため、このようなほとんどの階層化されたアーキテクチャを削除しました。典型的な宇宙飛行士のアーキテクチャです。私は以下を使用しています：

1. ASP.Net MVCのフォーム/ビューのモデルを表示します。これは重要なデカップリング手順です。 UIは通常、モデルとは別に進化します。
2. サービスレイヤーがなく、代わりに小さな操作とクエリをそれぞれ表す「コマンドハンドラ」（変更操作）と「ファインダ」（クエリ操作）（CQS - コマンドクエリ分離）で置き換えます。
3. モデル内でNHibernateおよびALLドメインロジックを使用したモデルの永続性。
4. 任意の外部サービスは、ファインダとコマンドハンドラに話すだけでなく

これは、低カップリングで非常にフラットに管理アーキテクチャにつながり、これらすべての問題が離れて行きます。