3

MVCアプリに「Stores」というクラスがあり、他のいくつかのフィールドの値に依存する「IsInCompliance」というクラスがあります。ロジックは通過し、「これ、これ、およびこれが真である場合、IsInComplianceは真である」と言います。

これはモデル定義に含める必要がありますか、それともこのロジックをサービスレイヤーまたはコントローラーに配置する方が適切ですか？私には4つの選択肢があると思います。

  1. モデル内のメソッドに含まれるロジック
  2. モデルに書き戻すコントローラーに含まれるロジック
  3. モデルが呼び出すサービスに含まれるロジック
  4. コントローラが呼び出すサービスに含まれるロジック

どちらがベストですか？3が最適な場合、循環依存関係はありませんか（私のモデルプロジェクトは、モデルプロジェクトに依存するサービスプロジェクトに依存しているため）？

4

5 に答える 5

3

4番が正しいアプローチです。

コントローラーは、薄い「トラフィック制御」レイヤーとして機能し、すべてのロジックをその下のサービス レイヤーに委任する必要があります (または、あまりにも明白なロジックでない場合は、ビジネス レイヤーに委任しますが、それは別のアーキテクチャの問題です)。

モデルは通常、純粋な POCO 構造である必要があり、オプションでデータ モデルの内部にあるもののマイクロ ロジックを使用できます。たとえば、ID 生成とデータ整合性操作です。

ロジックのほとんど (比較的単純な / CRUD ベースのアプリの場合) は、通常、サービス レイヤーに配置する必要があります。

于 2013-02-18T02:42:42.377 に答える
3

これは好み/スタイルの問題ですが、Model オブジェクトに密接に関連するメソッドはそのオブジェクトに属すると常に信じてきました。

これを例に取ります (VS.NET インスタンスを開いていない状態でオンザフライでコーディングしているため、構文エラーがあればご容赦ください。これを通信手段として使用しようとしているだけです)。

public class Person 
{
    public Int32 Age { get; set; }

    public bool IsEligibleToEnterLegallyBindingContract() 
    {
        return Age >= 18;
    }
 }

独自のプロパティを内省し、他のモデル オブジェクトのメッセージやプロパティに依存しないメソッドを含むモデル オブジェクトは、MVC 環境での優れたオブジェクト設計および優れたモデリング アプローチであると断言します。

更新これについて同僚と話し合ったところ、彼はMartin Fowler による優れた記事であるAnemic Domain Modelを紹介してくれました。同僚がこの記事を勧めた後、私はこの記事を数回読みました。

Fowler 氏の記事の最後の段落 (これは martinfowler.com からの直接の引用であり、そのサイトの著作権は認められています):

「一般に、サービスで多くの動作を見つけるほど、ドメイン モデルの利点を奪う可能性が高くなります。すべてのロジックがサービスにある場合は、自分自身を盲目的に奪っていることになります。」

于 2013-02-18T02:48:05.290 に答える
0

通常、私はモデル内ではなくモデルに対してアクションを実行しますが、これは一種の個人的な好みです。私は（あなたの場合）サービスレイヤーにロジックを書き、モデルで機能するコントローラーから調整呼び出しを行います。とはいえ、これをAnemic Domain Modelと呼ぶ人もいると思います。

どのアプローチも間違っているとは思いませんが、個人的には 4 番を選びます。

于 2013-02-18T02:53:53.597 に答える
0

それはあなたのコーディングスタイルに依存すると思います。

誰に質問するかによって、オプション 1 またはオプション 4 のいずれかが正しいと言えます。

このようなものについては、オプション 1 が正しいと思います。

IsInCompliance がモデル内の他のプロパティの値のみに依存する場合は、モデル内にある必要があります。

IsInCompliance の値が他のクラスに依存する場合は、はい、サービス層にある必要があります。

このようなものをサービス レイヤーに移動すると、モデル クラスが dto だけになってしまう Anemic Domain モデルが発生します。

オブジェクト指向設計では、これはアンチ パターンと見なされます。

サービス層に必要なものはまだたくさんありますが、これはその 1 つではないと思います。

于 2013-02-18T10:42:02.423 に答える
0

MVC は、懸念を分離することがすべてです。そのままにしている。ビジネス ロジックを別のクラス (レイヤー) に配置して、ロジックをデータから分離します。

于 2013-02-18T02:49:54.663 に答える