我在我的 MVC 应用程序中使用 UnitOfWork/Service Layer/Repository/EF4 w/POCO 设计。
到目前为止，我有这个：
1) MVC Web App (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.Domain（POCO 类）。
我目前在 Project.Data.dll 中有 UnitOfWork 接口/基础，但现在所有层都必须引用它。这是一个糟糕的设计吗？如果是这样，它住在哪里？
如果您使用依赖注入，我认为会更好。你可以看看这篇很棒的帖子：http ://blog.keithpatton.com/2009/05/30/Entity+Framework+POCO+Repository+Using+Visual+Studio+2010+Net+40+Beta+1.aspx
这只是一个意见。
领域对象是业务的一部分。上下文和存储库也是如此。
事实上，我的观点是 OR/M 是对关系数据库或其他类型存储的抽象，因此它们可以充当面向对象的存储。
这就是 OR/M 抛弃了现代软件解决方案中的数据层。
存储库、域上下文、域对象是业务层的一部分。
工作单元是一种软件设计模式，它不仅用于处理数据库或数据层，还可以管理更多事物，例如网络事务。我建议这应该包含在一些命名空间中，比如“YourCompany.YourProject.Patterns.UnitOfWork”或类似的东西。
服务与数据无关。我想建议一个“YourCompany.YourProject.Services”命名空间。
另一点是您的 POCO 似乎也可以作为 DTO 工作，因为您在任何地方都在使用，甚至用于通过层和/或层传递数据。这在裸对象实现或类似的东西中可能没问题，但您需要注意使用域对象作为 DTO 的事实，因为它们可能包含属性、信息、行为或 OR/M 代理隐藏成员可能影响对象的重量-内存使用-。
考虑最后一段事实，我建议您在业务之上的任何层使用 DTO，因此您的服务将返回具有服务消费者需要正常工作的特定属性范围的 DTO。
DTO、模式的实现以及在所有项目中共享的此类内容，您的解决方案的一部分应该存在于某个名为“YourProject.Shared”的项目中，并且此程序集不得引用任何层：它必须保持层中立，因此在任何地方都引用它不会强制拥有无用的依赖项。
好吧，这是我的观点和在我的项目中工作的方式。
如果您不希望其他层引用 Data 项目，您必须分离IUnitOfWork到单独的项目并使用依赖注入和一些控制容器的反转。
看看https://github.com/sharparchitecture/Sharp-Architecture它有一个 Northwind 示例，它与您的一样分层。您将看到 UnitOfWork 实现。