サービス層とリポジトリ

Question

私は、しばらくの間MVCフレームワークを使用してきましたが、懸念がどのように分離されるかがとても気に入っています。私は、コントローラーにかなりの仕事をさせるという悪い習慣に陥りました。だから私は本当にいくつかのアドバイスを探しています。

MVCを初めて使用したとき、データベースの作業が完了した後、コントローラーでモデルを操作することがよくありました。私はこれが悪いことを知っていたので、その仕事をモデルに移しました。しかし、自分のモデルを非常に学習してもらいたいので、それには満足していません。

少し読んでみましたが、サービス層があることで、人々はコントローラーやモデルを無駄にしないようにしています。

サービスレイヤーとリポジトリがどのように連携するかを理解しようとしています。ここに私の仮定がありますが、これが良い働き方であるかどうか教えてください。

1. データに対して操作を行う必要がない場合、コントローラーはリポジトリを直接呼び出すことができます。そのため、サービスレイヤーを関与させる必要はありません
2. データ（ビジネスロジック）に対して何らかの作業を行う必要がある場合、サービスレイヤーでこれを行う必要があり、コントローラーは必要に応じてサービスレイヤーへの単純な呼び出しを行います
3. サービスのビジネスロジックが完了すると、必要に応じてリポジトリを使用します（データを保持する必要がある場合）。
4. モデルは理想的には無駄のない状態に保ち、理想的にはDTOとしてのみ機能するようにしてください
5. データの検証は、モデル内で行われます（MonoRail検証属性を使用）。たくさんの属性でモデルを汚染するのは好きではありませんが、それは別の議論です。 UIでの自動jQuery検証に対するMonoRailの検証属性の利点が気に入っています。

すべてのコードを単一の責任原則に変えようとしているため、コーディングのプラクティスを整理しようとしています。

ありがとう

Answer 1

まず、すべての状況で機能する一連のルールはありません。アプリケーションをどのようにモデル化するかは、プロジェクトのタイプと複雑さに大きく依存します。そうは言っても、ここにいくつかのアイデアがあります：

1. コントローラからリポジトリを呼び出すことに問題はありません。コントローラーにビジネスロジックが含まれていないことを確認してください。
2. サービスは（一部の）ビジネスロジックを処理し、他のサービスを使用してそうします。リポジトリはサービスの一種であり、サービスから呼び出すのに問題はありません。
3. モデルにはビジネスロジックが含まれている必要があります 、実際には常に最初にモデルに配置するようにしてください。 （別のモデルまたはリポジトリから）そのビジネスロジックを実行するために外部データが必要な場合は、サービスを作成する必要があります。
4. モデルの検証に問題はありません。属性を使用するかどうかは、好みの問題です（気に入った場合は良いことです）。検証が複雑すぎる場合は、検証をモデルの外に移動します（ルールの外部セットを作成します）。

最も重要なことは、正しいと思うことをすることです（通常は正しい答えです）。

Answer 2

このビデオは素晴らしいasp.net MVCソリューションを整理し、懸念事項の分離に対処する方法の洞察、およびテスト容易性の向上。うまくいけば、それは他の誰かにも役立つでしょう。私はそれからいくつかの良いことを学びました。

Answer 3

Ian Cooperはこのテーマに関するファットコントローラー。