EF 4.1では、DBSet <Something>ではなくDBSet <ISomething>を使用できますか？

Question

私はビジネスメソッドを持つドメインモデルを構築しようとしており、EF 4.1で永続化を行っています。ここまでは順調ですね。

問題は、すべてのプロパティが自分のドメインクラスでパブリックとして公開されていることです。とにかく私がチュートリアルから学んだことは少なくともそれです。つまり、ビジネスメソッド以外の不注意なプログラマによってクラスプロパティが変更されないという強力な証拠はありません。カプセル化が犯された。

私は何かを導入しようとしましたが、TableAttributeはインターフェイスではなくクラスにのみ適用されるため、EFにDBSetを実行させることはできません。私はクラスにTableAttributeを残すが、何かとにかく何かを実装する場合、EFがISomethingを知らないのでDBSet.Add（）を実行できません。

私が考えることができる唯一の方法は、インターフェイスを使用するCRUDのEF 4.1の上に完全な抽象レイヤを書き込むことです。フードの下で、SomethingとIsomethingの間のタイプ変換を行います。 EFのデザインには、複雑さと大きな欠点がありました。または、私は何かを逃したに違いない。

どうすれば解決できますか？

多くのありがとうございます。

Answer 1

問題は、すべてのプロパティが自分のドメインクラスで公開されているということです。 これは少なくとも私がチュートリアルで学んだことです。つまり、 は、ビジネスメソッドの外にある一部の 不注意なプログラマーによってクラスプロパティが変更されないという強力な証拠がありません。カプセル化 が違反しました。

これはインターフェイスによってどのように解決されますか？ Interfaceは再びすべてのプロパティをpublicとして公開し、EFはプロパティにgetterとsetterが必要であることを要求します。

EFはインターフェイスで動作できません。マッピングにEDMXを使用すると、プロパティのアクセシビリティで少し再生することは可能ですが、最初にコードを使用すると、マッピングは同じアクセシビリティルールの影響を受けるため、はるかに悪くなります。 EFの上に抽象レイヤーを作成することは、EFをまったく使用しないこととほとんど同じです。抽象化を作成すると、linq-to-entitiesを直接使用することはできず、EFを使用する主な理由が失われます。

あなたの問題の詳細は次のとおりです。境界はどこですか？ビジネスメソッドでのみエンティティを操作する場合は、これらのメソッドからエンティティを公開しないでください。プロパティが正しく処理されているかどうかを確認したい場合は、検証ロジックをエンティティに直接実装する必要があります。