web-dev-qa-db-ja.com

コントローラがサービスの代わりにドメインオブジェクト（エンティティ）を直接呼び出すのは悪い習慣ですか？

コントローラがサービスの代わりにドメインオブジェクトのメソッドを直接呼び出すのは悪い習慣ですか？

詳細を説明するには：

良い設計では、コントローラーはサービスを呼び出し、サービスはドメインオブジェクト（エンティティ）を使用します。

しかし、コントローラーでは、ロジックを必要としない場合があり、dbからフェッチしてそれをビューに渡す必要があるだけです。

ドメインオブジェクト（エンティティ）のメソッドを呼び出すだけでそれを行うことができます-サービスを呼び出す必要はありません-それは悪い習慣ですか？

例として

Class Student{

public function getName(){//return the student name};
public function setName(){//setting the the student name};

}

コントローラから直接getName（）メソッドにアクセスする

design-patternsobject-orientedmvcentitydomain-objects
4
Susantha7

元のMVCアーキテクチャ

元のMVCアーキテクチャ（1979年のXerox PARC）では、コントローラーがユーザーの操作を処理します。モデルおよび1つまたは複数のビューと対話します。責任の分割には、ビューの責任であるレンダリングにコントローラーが介入しないことが必要です。

このアーキテクチャでは、サービスは必要ありません。コントローラがドメインオブジェクトに直接アクセスすることは完全に有効です。

MVCの子孫

これは、プレゼンター（別名コントローラー）がビューとモデルの間の仲介者として機能する [〜＃〜] mvp [〜＃〜] アーキテクチャ（1996年にTalligentによって最初に導入された）とは異なります。クライアントサーバーアーキテクチャでは、プレゼンターは、ドメインモデルが維持されているサーバーと、ビューを処理するクライアントの間で分割される可能性があるという考えです。

これが、MVPでは、コントローラーが「コマンド」と「選択」を通じてのみモデルにアクセスすることになっている理由です。したがって、ここではサービス層を使用する必要があります。

サービスレイヤーかどうか

この記事 は、MVC、MVP、MVVMの違いを明確にします。

残念ながら、フレームワークはしばしばMVCを独自に理解しています（例 Apple または Google Chrome team ）。使用しているMVCフレームワークは明確ではありません） ：必要に応じて、質問を編集して明確にします。

それにもかかわらず、MVCに関係なく、ドメインはAPIを介して複数のアプリケーションによって使用される（またはマイクロサービスとして実装される）ことになっている可能性があります。次に、MVCのためではなく、他のアーキテクチャ上の考慮事項のために サービスレイヤー が必要になる可能性があります。

4
Christophe

@Christopheは、MV *パターンでのサービスへのアプローチに関して優れた回答を提供していると思います。ドメインドリブンデザインに関する質問の場合は、回答を追加します。

DDDアプローチでは、質問に対する答えは「いいえ、それは間違いではありません」です。通常は、ドメインモデルのみを使用して設計を開始し、ドメインモデルと直接対話して、それらのメソッドを直接呼び出します。通常、単一のエンティティの範囲外の動作を調整する必要があるか、アプリケーション（データベースやWebサービスなど）の外部の懸念事項とやり取りする必要があるため、サービスを必要とする場合にのみ要素を考慮します。

1
Paul