在使用实体框架的分层架构中，我应该从 BLL 返回 POCO 类吗?(需要架构指导) [英] In a layered architecture using Entity Framework, should I return POCO classes from the BLL? (Architecture guidance needed)

问题描述

我可能阅读过多，并且正在遭受一些信息过载的困扰.所以我希望得到一些明确的指导.

I've been reading too much probably and am suffering from some information overload. So I would appreciate some explicit guidance.

从我收集到的信息来看，我可以使用 VS2010 的 T4 模板生成不直接绑定到 EF 的 POCO 类.我会将这些放在他们自己的项目中，而我的 DAL 会有一个 ObjectContext 派生类，对吗?

From what I've gathered, I can use VS2010's T4 template thingy to generate POCO classes that aren't tied directly to the EF. I would place these in their own project while my DAL would have an ObjectContext-derived class, right?

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

Once I have these classes, is it acceptable practice to use them in the UI layer? That is, say one of the generated classes is BookInfo that holds stuff about books for a public library (Title, edition, pages, summary etc.).

我的 BLL 将包含一个 BooksBLL 类，例如:

My BLL would contain a class BooksBLL for example like so:

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 实例.可以吗?

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

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

Furthermore, MVVM posts on the Web suggest implementing IDataErrorInfo for validation purposes. Is it okay if I implement said interface on the generated POCO class? I see from samples that those generated POCO classes contain all virtual properties and stuf and I hope adding my own logic would be okay?

如果有什么不同，目前我的应用程序不使用 WCF(或任何网络内容).

If it makes any difference, at present, my app does not use WCF (or any networking stuff).

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

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.

更新(根据要求提供其他信息):

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

I'm trying to create a library automation application. It is not network based at present.

我正在考虑如下分层:

• 由生成的 POCO 类(BookInfo、作者、成员、出版商、联系人等)组成的项目
• 具有 ObjectContext 派生类 (DAL?) 的项目
• 一个业务逻辑层，其中包含我上面提到的类(BooksBLL、AuthorsBLL 等)
• 使用 MVVM 模式的 WPF UI 层.(因此是我关于 IDataErrorInfo 实现的子问题).

所以我想知道诸如在 ViewModel 类中使用 BooksBLL 的实例，在其上调用 ResolveSearch() 以获取 List; 并展示它……也就是说，到处使用 POCO 类.

So I'm wondering about stuff like using an instance of BooksBLL in a ViewModel class, calling ResolveSearch() on it to obtain a List<BookInfo> and presenting it... that is, using the POCO classes everywhere.

或者我应该有其他类来反映从我的 BLL 公开的 POCO 类吗?

Or should I have additional classes that mirror the POCO classes exposed from my BLL?

如果需要更多细节，请询问.

If any more detail is needed, please ask.

推荐答案

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

You don't need to do anything in particular... as Mark said, there is no "right" answer. However, if your application is simple enough that you would simply be duplicating your classes (e.g. BookInfoUI & BookInfoBLL), then I'd recommend just using the business classes. The extra layer wouldn't serve a purpose, and so it shouldn't exist. Eric Evans in DDD even recommends putting all your logic in the UI layer if you app is simple and has very little business logic.

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

To make the distinction, the application layer should have classes that model what happens within the application, and the domain layer should have classes that model what happens in the domain. For example, if you have a search page, your UI layer might retrieve a list of BookSearchResult objects from a BookSearchService in the application layer, which would use the domain to pull a list of BookInfo.

这篇关于在使用实体框架的分层架构中，我应该从 BLL 返回 POCO 类吗?(需要架构指导)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！