Microsoft Entity Framework/Linq to SQLを使用した自己完結したモジュラークラス

Question

私は数年間Webプログラミングに.NET 2を使用してきました。最近いくつかの新しいプロジェクトに.NET 4を使用することを検討し始めました。

私は、SQLへのMicrosoft Entity Framework/Linqの使用方法を学びました。それは基本が非常に簡単になるように見えるし、完全に機能するクラスをまったく一緒にまとめることができます。しかし、今私はもう少しそれをプッシュし始めている、私は周りを回避する方法がわからない問題を見つける。

私に迷惑をかけることの1つは、私が物事を整理する方法を理解していないということです。明らかに私は関連するクラスを名前空間に保持することに慣れており、一般的にこれらの名前空間はデータベースのレイアウトを反映しています（たとえば、名前空間はテーブル名プレフィックスにマップされます）。しかし、EFを使用すると、すべてのクラスが同じ名前空間になければならないようです。私はもちろん、別々の名前空間にいくつかのデータコンテキストを持つことができますが、クラスがもはや互いに関係を持たないため、EFが提供する利点が失われます。私はこれで生きることができますが、私は何かを欠いている必要があるように感じる？

私が気になっているもう一つの問題は、私が自己完結型モジュラークラスを構築することに慣れていることです。これはEFでどうやって可能か理解できません。たとえば、db.SaveChanges（）を呼び出すとデータベース全体の変更が保存され、mySingleObject.Save（）が呼び出されている場合、これは単純なSave関数を作成する方法を理解できません。あなたがしゃべっている他のオブジェクトの変更を保存するので、やりたいことのように思えます。クラスライブラリの外部からdb.SaveChanges（）を呼び出さなければならないことは、私のクラスライブラリの外にあるものは自分のデータがどのように格納されているかの知識を必要とすべきではないので、狂っているように思えます。

私はこの点を見逃しているのですか、私の考え方を変える必要がありますか？

現時点では、私はこれらの問題のためにプロジェクトを進めるのに苦労しています。私は平凡な古いSQLに戻ることを検討しています。 EFには明らかに大きなメリットがあるので、これは残念ですが、私はそれを最大限に活用したいと思います！

Answer 1

私は、すべてのデータベースエンティティを同じ名前空間に保持しなければならないという問題に遭遇したことはありません。とにかくデータベースに関係する名前空間を作成するのは明らかです。私は緊密な結合を導入することをお勧めします。これは、一緒に避けるのが最善です。具体的には、アプリケーションは基礎となるデータストアのスキーマに気を付けるべきではありません。名前空間は、論理エンティティ（つまり、ロギングに関連するすべてのクラス、またはこの場合は永続ストアとのやり取りに関連するすべてのクラス）をグループ化（およびスコープ）するためによく使用されると思います。

あなたの他の懸念も私には根拠がないようです。オブジェクト状態をストアにコミットする場合と、ストアにオブジェクト状態をコミットしたい場合の例を挙げることはできますか？ EFはトランザクションを実行するためのメカニズムを提供しています。

一般に、データベース内の行を表す単一クラスのactive record patternは無効になり、リポジトリパターン（previous question,msdn）が使用されています。