ロジック配置のジレンマがありますが、ここから始めるのが私のアプリ レイヤーです。
- プレゼンテーション/UI レイヤー (Web API または MVC、実際には何でもかまいません)
- サービス層 (この層は全体的に無駄がなく、ドメイン モデルとリポジトリ層のコンダクターとして機能します)
- ドメイン モデル (このレイヤーは貧血ではなく、モデル クラスにデータと動作の両方があります)
- リポジトリ
現状では、レイヤーは適切に設計されており、フローは直感的です. ただし、純粋なモデル データをいくつかの特定の XML ドキュメントに整形し、.xsd スキーマを介して検証する必要があります (モデル クラスはXML ドキュメントに対して 1:1 をマップしないか、オブジェクトを直接 XML にシリアル化できます)。私にとって、モデルレイヤーは、現在の設計を超えて形作られたり構造化されたりすることを理解しているべきではありません。それは上位層の責任です。
私が最初に考えたのは、ViewModel クラスを介してServiceレイヤーのドメイン モデル データからこれらの XML ドキュメントを作成し、上位レベルに戻すためのシェーピングとロジックを提供することです。ここで「ViewModel」という用語を使用して、純粋に上位レイヤーまたはプレゼンテーション用の成形データを意味します。ただし、私が読んだすべてのことは、サービス層に ViewModels を含めるべきではないと言っています:サービス層は MVC アプリケーションのビュー モデルを返す必要がありますか? ASP.NET MVC で複雑な ViewModel をサービス層に渡す方法は?
これを 1 分間実行して、MVC レイヤーに ViewModel を含めます。これには問題があります。サービス レイヤーを使用する全体的な理由は、アプリケーションへのファサードまたはエントリ ポイントとして機能し、複数の UI タイプ (WinForms、WPF、WebForms、MVC、WCF など) を使用できるようにするためです。サービス層に接続するすべてのUI で利用できる XML 整形ロジックが必要です。MVC/UI 層に置いた場合、新しい UI を接続すると存在しなくなります。
ここで、XML シェーピング クラスをサービス層にプッシュする作業に戻ります。また、これらのクラスをドメイン層に置くべきではないと思います。これはビジネス ロジックではなく、形式の種類である XML を示しているためです。これは望ましくありません。最後に、このロジックをインフラストラクチャ レイヤーのような垂直レイヤーに導入することはできません。なぜなら、このレイヤーはドメイン モデルを理解し、荷物のように持ち運ばなければならないからです。
本Professional ASP.NET Design Patternsによると、このアーキテクチャを使用する場合、次のように述べられています。プレゼンテーション モデルと呼ばれることもある、強く型付けされたビュー モデルを持つプレゼンテーション レイヤー。 シェイプされたクラスをサービス レイヤーに配置したいと考えています。これが最適と思われ、この方法で実行された例を見てきました。
ロジックはどこに属しますか? 1..n 個のドメイン モデル クラスを取得し、さまざまなデータを使用して XML ドキュメントを作成し、それを UI/プレゼンテーション レイヤーで使用できるようにしたいですか? ありがとう！