1

次のビジネスエンティティクラスについて考えてみます。自分自身を検証するには、おそらく何らかの競合を防ぐために、データベースの状態について何かを知る必要があります。したがって、このデータを取得するために、データアクセス層に依存します。

状態をカプセル化し、状態を検証し、データストアにアクセスしてそうするクラスを持つことは、単一責任原則の違反ですか？

class MyBusinessObject
{
    private readonly IDataStore DataStore;

    public MyBusinessObject(IDataStore dataStore)
    {
        this.DataStore = dataStore;
    }

    public virtual int? Id { get; protected set; }
    public virtual string Name { get; set; }
    // ... Other properties...

    public IEnumerable<ValidationResult> Validate()
    {
        var data = this.DataStore.GetDataThatInfluencesValidation();
        return this.ValidateUsing(data);
    }

    // ... ValidateUsing method would be in here somewhere ...
}

それは私にとって赤い旗を投げています：

  • ASP.NET MVCコントローラーのCreateメソッドのコンテキストでは、新しいインスタンスを作成して、検証する意図なしにView（）メソッドに渡す可能性があります。それでは、なぜIDataStoreを渡す必要があるのでしょうか。
  • 私はNHibernateを使用しています（そして私は初心者です）。NHがエンティティを作成するたびに依存関係を挿入するIInterceptorを作成する必要があるようです。たぶんそれでいいのですが、少し違和感があります。

NHibernateが使用するのに貧血/DTOタイプのオブジェクトを使用し、それをすべてのビジネスルールを知っていて、データストアに依存している場合はデータストアにアクセスできる何かにラップする必要があると考え始めています。質問とタイトルを入力したので、StackOverflowはいくつかの興味深いリソースを提案しました：こことここ。

私の質問もこれと非常によく似ていますが、私の状況により近い別の方法で質問したいと思いました。

4

1 に答える 1

1

「状態をカプセル化し、状態を検証し、データストアにアクセスしてそうするクラスを持つことは、単一責任原則の違反ですか？」-あなたは3つの責任を挙げたので、私はそう答えるつもりです。

検証の難しさは、コンテキストに依存することです。たとえば、顧客レコードを作成するには名前だけが必要ですが、製品を販売するには支払い情報と配送先住所が必要です。

MVCでは、ビューモデルのデータ注釈を使用して低レベル（データサイズとnull可能性）の検証を行います。より複雑な検証は、仕様パターンを使用して行われます。仕様パターンは実装が簡単で柔軟性があります。

于 2013-01-12T14:25:30.793 に答える