使用Microsoft Entity Framework/Linq to SQL的自包含模块化类

Question

多年来，我一直在使用.NET 2进行网络编程（由于我们对于我们使用的服务器上的其他内容的支持有限），但最近开始着眼于将.NET 4用于一些新项目。

作为这一部分，我一直在试图学习如何使用Microsoft Entity Framework/Linq to SQL。它似乎使基础知识变得非常简单，你可以立刻组装一个功能齐全的课程。但是，现在我开始进一步推进它，我发现了一些问题，我不知道如何解决。

困扰我的一件事是我不懂如何组织事情。很显然，我习惯于在名称空间中保留相关的类，通常这些名称空间反映了数据库的布局（例如，名称空间映射到表名前缀）。尽管使用EF，似乎我的每个类都必须位于同一个命名空间中。我当然可以在单独的命名空间中使用多个数据上下文，但是随着类别彼此之间不再有任何关系，我将失去EF提供的优势。我可以忍受这一点，但我觉得我必须错过什么？

我遇到的另一个问题是我更加困扰的是我习惯于构建独立的模块化类，我不明白EF如何实现这一点。例如，我无法弄清楚如何编写一个简单的Save函数，因为如果调用db.SaveChanges（），那么整个数据库的改变都会被保存 - 如果你调用了mySingleObject.Save（），那么它不会' t看起来像是一个理想的事情，因为它也可以保存任何其他对象的变化。考虑到我将这个功能构建到类库中，必须从类库外部调用db.SaveChanges（），这似乎也很疯狂，因为我的类库之外的任何东西都不需要任何有关如何存储数据的知识。

我是否错过了这一点或者是否需要改变我的思维方式？

目前我正在努力推进我的项目，因为这些问题，我正在考虑回到普通的旧SQL。这将是一个耻辱，因为EF显然有一些巨大的优势，我想充分利用它！

Answer 1

我从来没有遇到过必须将所有数据库实体保留在同一个命名空间的问题。我不认为很明显，会创建与数据库相关的命名空间。我认为引入紧密耦合最好避免所有这些紧密耦合，特别是应用程序不应该关心底层数据存储的模式。我认为命名空间通常用于对逻辑实体（即范围）进行分组（即范围） - 即与日志记录有关的所有类，或者在这种情况下，与与持久性存储库交互相关的所有类。

您对我的其他担忧似乎同样没有根据。你能提供一个例子，说明你什么时候想要将某些对象状态提交给商店而不是其他人？ EF提供了执行交易的机制，所以你在这方面很好。

一般来说，表示数据库中一行的单个类的active record pattern正在失宠，并且存储库模式（previous question,msdn）正在取代它。