在使用实体框架的分层架构中，我应该从 BLL 返回 POCO 类吗？ （需要架构指导）

Question

我可能读得太多了，并且遭受了一些信息超载的困扰。所以我希望得到一些明确的指导。

根据我收集的信息，我可以使用 VS2010 的 T4 模板来生成不直接与 EF 绑定的 POCO 类。我会将这些放在他们自己的项目中，而我的 DAL 将有一个 ObjectContext 派生类，对吧？

一旦我有了这些类，在 UI 层使用它们是否可以接受？也就是说，假设生成的类之一是 BookInfo，它保存有关公共图书馆书籍的信息（标题、版本、页面、摘要等）。

我的 BLL 将包含一个类 BooksBLL ，如下所示：

public class BooksBLL
{
    ObjectContext _context;

    public void AddBook(BookInfo book) { ... }
    public void DeleteBook(int bookID) { ... }
    public void UpdateBook(int bookID, BookInfo newBook) { ... }

    //Advanced search taking possibly all fields into consideration
    public List<BookInfo> ResolveSearch(Func<BookInfo, bool> filter) { ... }

    //etc...
}

因此，我的 MVVM UI 应用程序中的 ViewModel 将与上述 BLL 类进行通信并交换 BookInfo 实例。可以吗？

此外，MVVM 在 Web 上的帖子建议实现 IDataErrorInfo 来进行验证。如果我在生成的 POCO 类上实现所述接口可以吗？我从示例中看到那些生成的 POCO 类包含所有虚拟属性和内容，我希望添加我自己的逻辑可以吗？

如果有什么区别的话，目前我的应用程序不使用 WCF（或任何网络东西）。

另外，如果您发现我尝试构建 BLL 的方式存在严重错误，也请随时提供该领域的帮助。

更新（根据要求提供其他信息）：

我正在尝试创建一个图书馆自动化应用程序。目前它不基于网络。

我正在考虑具有如下层：

• 由生成的 POCO 类（BookInfo、Author、Member、Publisher、Contact 等）组成的项目
• 具有 ObjectContext 派生类（DAL？）的项目
• 具有此类类的业务逻辑层我上面提到（BooksBLL、AuthorsBLL 等）
• 使用 MVVM 模式的 WPF UI 层。 （因此我提出了关于 IDataErrorInfo 实现的子问题）。

因此，我想知道诸如在 ViewModel 类中使用 BooksBLL 实例、调用 ResolveSearch() 来获取 List 等内容。 code> 并呈现它...也就是说，到处使用 POCO 类。

或者我应该有额外的类来反映从我的 BLL 公开的 POCO 类吗？

如果需要更多详细信息，请询问。

Answer 1

您所做的基本上是存储库模式，实体框架和 POCO 非常适合该模式。

因此，我的 MVVM UI 应用程序中的 ViewModel 将与上述 BLL 类进行通信并交换 BookInfo 实例。这样可以吗？

这正是 POCO 对象的用途；生成的类和手动编写它们的方式没有区别。您的 ObjectContext 封装了将任何更改保留回数据库的所有逻辑，并且不会直接暴露给您的 UI。

我个人并不熟悉 IDataErrorInfo 但如果现在您的实体仅在这个单个应用程序中使用，我认为没有任何理由不将其直接放入生成的类中。如果可能的话，将其添加到 T4 模板将是理想的选择，如果错误消息遵循任何逻辑模式，那么您将不必为每个类手动编码。

此外，如果您发现我尝试构建 BLL 的方式存在严重错误，也请随时提供该领域的帮助。

无论如何，这并不是完全错误，但如果您计划针对 BLL 编写单元测试（我推荐），您将需要更改您的 ObjectContext 成员到IObjectContext。这样，您就可以在运行时替换任何实现 IObjectContext 接口的类（例如您的实际 ObjectContext），这将允许您进行测试内存中（即模拟）上下文，而不必访问数据库。

同样，考虑将 List 替换为某种接口，例如 IList 或 IBindingList 或最小公分母IEnumerable。这样，您就不会直接与特定的类 List 绑定，并且如果您的需求随着时间的推移而发生变化（这种情况往往会发生），它将减少替换 List所需的重构。 BookInfo> 与其他内容，假设您要替换它的任何内容都实现了您选择的接口。

Answer 2

您不需要做任何特别的事情...正如马克所说，没有“正确”的答案。但是，如果您的应用程序足够简单，您只需复制您的类（例如 BookInfoUI 和 BookInfoBLL），那么我建议仅使用业务类。额外的层没有任何作用，因此它不应该存在。如果您的应用程序很简单并且业务逻辑很少，那么 DDD 中的 Eric Evans 甚至建议将所有逻辑都放在 UI 层中。

为了进行区分，应用程序层应该具有对应用程序中发生的情况进行建模的类，而领域层应该具有对域中发生的情况进行建模的类。例如，如果您有一个搜索页面，您的 UI 层可能会从应用程序层中的 BookSearchService 检索 BookSearchResult 对象列表，这将使用域来拉取 BookInfo 列表。

Answer 3

您的问题的答案可能取决于您的应用程序的规模和复杂性。所以我担心也会有有效的论据来回答你的问题是和否。

就我个人而言，我会用“是”回答您的两个主要问题：

在 UI 层中使用 POCO（域）类是否可以接受？

我想“UI 层”实际上并不是指 View MVVM 模式的一部分，但 ViewModel 除外。 （我相信，大多数 MVVM 专家都会反对让 View 直接引用 Model。）

将 Domain 项目中的 POCO 作为属性包装到 ViewModel 中并将此包装的 POCO 直接绑定到 View 并不罕见。最大的优点是：很简单。您不需要在 ViewModel 中添加额外的 ViewModel 类或复制属性，然后在对象之间复制这些属性。

但是，如果您使用 WPF，则必须考虑到，如果将 POCO 属性绑定到视图，绑定引擎将直接写入 POCO 属性。这可能并不总是您想要的，特别是当您在 WPF 表单中使用附加的和更改跟踪的实体时。您必须考虑取消场景或如何在取消后恢复已被绑定引擎更改的属性。

在我当前的项目中，我正在使用分离的实体：我从数据层加载 POCO，将其与上下文分离，处理上下文，然后在 ViewModel 中使用该副本并将其绑定到视图。数据层中的更新是通过创建新上下文、按 ID 从数据库加载原始实体，然后更新绑定到视图的更改后的 POCO 的属性来实现的。因此，通过这种方法，附加实体的意外更改问题就消失了。但与独立的实体合作也有缺点（例如更新更复杂）。

如果我在生成的 POCO 类上实现 IDataErrorInfo 接口可以吗？

如果您将 POCO 实体绑定到视图（通过包装 ViewModel），它不仅可以，而且如果您想利用 WPF 绑定引擎的内置属性验证，您甚至必须在 POCO 类上实现 IDataErrorInfo。尽管此接口主要与 UI 技术一起使用，但它是 System.ComponentModel 命名空间的一部分，因此不直接绑定到任何 UI 命名空间。基本上，IDataErrorInfo 只是一个简单的协定，它支持报告对象的状态，这在 UI 上下文之外也可能有用。

对于 INotifyPropertyChanged 接口也是如此，如果您将 POCO 类直接绑定到视图，您还需要在 POCO 类上实现该接口。

我经常看到由于某些架构原因而与我意见不一致的观点。但这些观点都没有认为另一种方法更容易。如果您严格希望避免在 ViewModel 层中使用 POCO 模型类，则需要添加另一个映射层，这会带来额外的复杂性以及编程和维护工作量。所以我会投票：只要你没有令人信服的理由和明显的好处来使你的架构变得更加复杂，就保持简单。