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

问题描述

我一直在阅读太多可能，正在遭受一些信息超载。所以我会感谢一些明确的指导。

从我收集到的，我可以使用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） {...} 
 
 //高级搜索可能考虑所有字段考虑
 public List< BookInfo> ResolveSearch（Func< BookInfo，bool> filter）{...} 
 
 // etc ... 
} 
  

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

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

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

另外，如果您看到我正在尝试构建BLL的方式有什么错误，请感觉

更新（附加信息请求）：

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

我正在考虑层次如下：

• 生成的POCO类（BookInfo，作者，成员，发布者，联系人等）


• 带有ObjectContext派生类（DAL？）的项目


• 一个类似上面提到的类的业务逻辑层（BooksBLL，AuthorsBLL等）


• 使用MVVM模式的WPF UI层。 （因此我的关于IDataErrorInfo实现的子问题）。

所以我想知道像使用 BooksBLL 在ViewModel类中，调用 ResolveSearch（）以获取列表< BookInfo> 并呈现它，也就是说，使用POCO类遍布各地。

或者我应该有其他类镜像从我的BLL暴露的POCO类？

如果需要更多的细节，请问。

解决方案

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

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

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

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?

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.).

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...
}

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

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?

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

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.

Update (Additional info as requested):

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

I am thinking about having layers as follows:

• A project consisting of generated POCO classes (BookInfo, Author, Member, Publisher, Contact etc.)
• A project with the ObjectContext-derived class (DAL?)
• A Business Logic Layer with classes like the one I mentioned above (BooksBLL, AuthorsBLL etc)
• A WPF UI layer using the MVVM pattern. (Hence my sub-question about IDataErrorInfo implementation).

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.

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

If any more detail is needed, please ask.

解决方案

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.

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.

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