我在MVC应用程序中使用UnitOfWork/Service Layer/Repository/EF4 w/POCO设计。UnitOfWork和分离的担忧？
到目前为止，我有这样的：
1）MVC Web应用程序（Project.dll）
2）服务层（Project.Data.Services.dll）
3）库层（Project.Data。 Repositories.dll）
4）POCOS（Project.Data.Domain.dll）
5）EF4 /背景层（Project.Data.dll）
每一层只引用下方的层和Project.Data 。域（POCO类）。
我目前拥有的的UnitOfWork接口/基地的Project.Data.dll，但现在所有的层必须引用。这是一个糟糕的设计？如果是这样，它住在哪里？
这只是一个意见。
域对象是业务的一部分。竞赛和存储库一样。
事实上，我的观点是OR/M是在商店的关系数据库或其他类型的抽象等等这些可以作为一种面向对象的商店采取行动。
OR/M在现代软件解决方案中抛弃了数据层。
存储库，域上下文，域对象是业务层的一部分。工作
单位是一种软件设计模式，它不仅处理数据库或数据层，但它可以管理更多的东西，如一个网络交易。我建议这应该包含在一些名称空间，如“YourCompany.YourProject.Patterns.UnitOfWork”或类似的东西。
服务与数据无关。我想建议一个“YourCompany.YourProject.Services”命名空间。
还有一点是你波苏斯似乎DTO工作过，因为你正在使用无处不在，即使通过层和/或层间传递数据。这可以在裸体对象实现或类似的事情中可以，但是您需要注意将域对象用作DTO的事实，因为它们可能包含属性，信息，行为或OR/M代理隐藏成员，这些成员可能影响物体的重量 - 记忆的使用 - 。
以最后一段其实，我建议你与DTO在业务上面一层的任何工作，所以你的服务将与该服务的消费者将需要正常工作性质的特定范围返回的DTO。
DTO，模式的实现和所有项目中共享的项目部分解决方案应该位于某个名为“YourProject.Shared”的项目中，并且此程序集不得引用任何图层：它必须保持图层不变，所以在任何地方引用它都不会强制产生无用的依赖关系。
那么，这是我的意见和工作方式在我的项目。
如果您使用依赖注入，我认为更好。你可能需要看看这个伟大的职位：http://blog.keithpatton.com/2009/05/30/Entity+Framework+POCO+Repository+Using+Visual+Studio+2010+Net+40+Beta+1.aspx
如果不希望其他图层引用数据项目，则必须将IUnitOfWork分开以分开项目，并使用依赖注入与控制容器的一些Inversion。
看看https://github.com/sharparchitecture/Sharp-Architecture它有一个Northwind的例子，它像你一样分层。你会看到UnitOfWork的实现。
@Mat - 我在我的MVC应用程序中使用查看/编辑模型，然后使用AutoMapper将pocos映射到模型。 – Sam 2011-03-03 07:30:03
好吧，我已经用你在你的问题中提到的信息回答了你！ ：D无论如何，我只是解释道，为了给你一个正确的命名方向，因为即使你使用AutoMapper或其他东西，用正确的命名来调用东西也是有意义的，所以源代码更易读，或者至少可以找到东西在正确的地方。 – 2011-03-03 07:32:50
@Mat - 所以你不认为存储库和以下是数据层？我会同意POCO是肯定的业务对象，但我认为这些存储库和ef是数据。没有？ – Sam 2011-03-03 07:42:22