1

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

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

ISomething を導入してみましたが、TableAttribute はインターフェイスではなくクラスにのみ適用されるため、EF に DBSet を実行するように指示できません。TableAttribute をクラスに任せても、何かに ISomething を実装させると、EF は ISomething を認識しないため、DBSet.Add() を実行できません。

私が考えることができる唯一の方法は、インターフェイスを使用して CRUD 用に EF 4.1 の上に完全な抽象化レイヤーを作成することです。内部で、Something と ISomething の間の型変換を行います。それは非常に複雑で、EF の設計にはぽっかり穴が開いているように思えました。または、何かを見逃したに違いありません。

これをどのように解決しますか？

どうもありがとう。

4

1 に答える 1

1

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

これはインターフェイスによってどのように解決されますか? インターフェイスは再びすべてのプロパティをパブリックとして公開し、EF はプロパティにゲッターとセッターが必要であることを要求します。

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

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

于 2011-07-27T09:07:53.813 に答える