[解決済み] ファットモデル・シンコントローラー vs. サービスレイヤー【終了しました

質問

私は長年にわたって、.Net を使用してエンタープライズアプリケーションを開発してきました。 私のアプリは通常、SQL DBテーブルにマッピングされたエンティティを含むドメインモデルを持っています。 私は、リポジトリパターン、依存性注入、およびサービスレイヤーを使用しています。

最近、私たちは MVC 3 プロジェクトに取り組み始め、どこにどのロジックを配置するかについて議論しました。 私は薄いコントローラ / FAT モデル アーキテクチャに出会い、サービス層がどのように適合するのか不思議に思っていました。

オプション 1 - サービスと対話するモデル

コントローラは薄く、モデル上のメソッドを呼び出します。モデルはDBから自分自身をロードする方法を知っており、リポジトリやサービスと対話します。 例えば、customerModel は Load(id) メソッドを持ち、顧客と GetContracts() のようないくつかの子オブジェクトをロードします。

オプション 2 - サービスと対話するコントローラ

コントローラはサービスにモデルオブジェクトを取得するよう依頼します。読み込み/保存などのロジックはサービス層にあります。サービス層にあります。モデルはデータのみの純粋なエンティティモデルです。

特にエンタープライズアプリケーションについて話すとき、なぜオプション1が良い選択なのでしょうか？私の経験では、関心事を分離し、モデルやコントローラをできるだけ薄く保ち、ビジネスロジック（DBのやり取りなど）を行う専門サービスを持つようにします。

すべてのアドバイスと良いリソースの参照に感謝します。

どのように解決するのですか？

これらはすべて、アプリケーションの意図と要件に依存します。

とはいえ、中規模（地元のレストランでもなく、TwitterやFacebookでもない）のWebアプリケーションに対する私の提案は以下のとおりです。

1. リーンドメインモデリング

   ドライPOCOスタイルのオブジェクトは、可能な限り特定の実装から疎結合のままにするために、WebアプリケーションのMVCアーキテクチャに無知であることが望ましいです。）

   MVC におけるモデルとは、正確には次のような意味です。 コントローラが認識するモデル であり、したがって はビューのために意図されたモデル .

   小さい（しばしばチュートリアル）アプリケーションでは、quot;アプリケーション/ドメインモデル層"のエンティティモデルは、しばしばコントローラがビューに出荷するオブジェクトと同じインスタンス化されたものです。

   大規模なアプリケーションでは、開発者はしばしば MVVM アーキテクチャの教義を採用し、個別のビューモデルオブジェクトを使用するようになります。コントローラは、しばしば、下の見えないエンティティで動作する中間層のサービスを呼び出します。このシナリオでは、MVCのMは、最も正確にビューモデルを意味します。

2. 堅牢なサービス層

   これは 肥満 ロジックを意味するのではなく、よく書かれた単一の目的のサービスを意味します。ビジネスロジックをモデルの外のサービスでコーディングすることは、純粋なOOPよりも少し手続き的ですが、疎結合、テスト、および柔軟な展開（N層展開など）に大いに役立ちます。

   私の個人的な実践では、私は、POCOオブジェクトの行動モデリング（永続化の仕組み、低レベルの検証など）を考慮するデータ層と、MVCの仕組みに近い高レベルのサービス（ビジネス/ワークフロー機能）の両方でサービスをコーディングしています。

3. リーンコン トローラ

   私は自分のコントローラが単に コーチ でもないという点で プレー (サービス) でも プレーヤー (エンティティモデルやビューモデル)ではなく、単に誰がどのポジションでどんなプレイをするかを決定します。私のコントローラは2つのことをします。

   1. エンティティ/ドメインと相互作用するサービスを呼び出す モデル

   2. 適切なViewのためのView Modelを用意する。

   認証/認可されたコントローラのアクションも、インジェクションされたサービス/属性を通じて行われます。

EDIT 1:

これは、あなたのエンティティ/ドメインモデルが貧弱である、または貧弱でなければならないことを意味するものではないことに留意してください。ORM、リポジトリ、ファクトリー、検証、または状態の仕組みは歓迎されます。これは、中程度の規模のアプリケーションでは モデル をMVCで表すと コントローラのためのモデルで、ビューに渡すためのものです。 .

この指摘が、を信じるFowlerの使徒たちを落ち着かせることを期待します。 貧弱なデータモデル であると信じている アンチパターン . 同時に、それは は は、モデル化されたクラスに振る舞いを含めることがより純粋である、OOPよりもわずかに手続き的な角度を反映しています。