c# - 在使用 Entity Framework 的分层架构中，我应该从 BLL 返回 POCO 类吗？ (需要架构指导)

Question

我可能读得太多了，正遭受着信息重载的困扰。因此，我将不胜感激一些明确的指导。

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

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

我的 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 帖子建议实现 IDataErrorInfo用于验证目的。如果我在生成的 POCO 类上实现所述接口(interface)可以吗？我从示例中看到那些生成的 POCO 类包含所有虚拟属性和 stuf，我希望添加我自己的逻辑可以吗？

如果有什么不同的话，目前，我的应用程序不使用 WCF(或任何网络的东西)。

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

更新(根据要求提供额外信息):

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

我正在考虑使用如下图层:

• 由生成的 POCO 类(BookInfo、Author、Member、Publisher、Contact 等)组成的项目
• 带有 ObjectContext 派生类(DAL？)的项目
• 一个业务逻辑层，其中包含我上面提到的类(BooksBLL、AuthorsBLL 等)
• 使用 MVVM 模式的 WPF 用户界面层。 (因此我提出了关于 IDataErrorInfo 实现的子问题)。

所以我想知道使用 BooksBLL 的实例之类的东西在 ViewModel 类中，调用 ResolveSearch()在上面获得 List<BookInfo>并展示它...也就是说，到处使用 POCO 类。

或者我应该有额外的类来反射(reflect)从我的 BLL 公开的 POCO 类吗？

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

Answer 1

您所做的基本上是 Repository 模式，Entity Framework 和 POCO 非常适合。

So, my ViewModels in my MVVM UI app will be communicating with the above BLL class and exchanging BookInfo instances. Is that okay?

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

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

Also, if you see something terribly wrong with the way I'm trying to build my BLL, please feel free to offer help in that area too.

无论如何这都不是非常错误，但是如果您计划针对您的 BLL 编写单元测试(我会推荐)，您将需要更改您的 ObjectContext加入 IObjectContext .这样你就可以替换任何实现 IObjectContext 的类运行时的接口(interface)(例如您的实际 ObjectContext)，这将允许您针对内存中(即模拟)上下文进行测试，而不必访问数据库。

同样，考虑更换您的 List<BookInfo>带有某种接口(interface)，例如 IList<BookInfo>或 IBindingList<BookInfo>或最小公分母IEnumerable<BookInfo> .这样你就不会直接绑定(bind)到特定类 List<T>如果您的需求随着时间的推移发生变化(这往往会发生)，它将减少替换您的 List<BookInfo> 所需的重构。用别的东西，假设你用什么替换它实现了你选择的接口(interface)。