单位工作和关注分离？

Question

我在我的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 / Context Layer（Project.Data.dll）

每个图层仅引用下面的图层和Project.Data.Domain（POCO Classes）。

我目前在Project.Data.dll中有UnitOfWork接口/ Base，但现在所有层都必须引用它。这是一个糟糕的设计吗？如果是这样，它住在哪里？

Answer 1

如果您使用依赖注入，我认为会更好。你可以看看这篇精彩的帖子：http://blog.keithpatton.com/2009/05/30/Entity+Framework+POCO+Repository+Using+Visual+Studio+2010+Net+40+Beta+1.aspx

Answer 2

这只是一种意见。

域对象是业务的一部分。上下文和存储库也是如此。

事实上，我的观点是OR / M是关系数据库或其他类型商店的抽象，因此这些可以充当面向对象的商店。

这是OR / M在现代软件解决方案中丢弃数据层。

存储库，域上下文，域对象是业务层的一部分。

工作单元是一种软件设计模式，它不仅适用于数据库或数据层，还可以管理更多内容，例如联网交易。我建议这应该包含在某些名称空间中，例如“YourCompany.YourProject.Patterns.UnitOfWork”或类似名称。

服务与数据无关。我想建议一个“YourCompany.YourProject.Services”命名空间。

另一点是你的POCO似乎也像DTO一样工作，因为你在任何地方都在使用，即使是通过层和/或层传递数据。这在裸体对象实现或类似的东西中可能没问题，但是您需要注意使用域对象作为DTO的事实，因为它们可能包含属性，信息，行为或OR / M代理可能隐藏的成员影响对象的重量 - 内存使用 - 。

考虑到最后一段事实，我建议您在业务之上的任何层中使用DTO，因此您的服务将返回具有服务消费者需要正常工作的特定属性范围的DTO。

DTO，模式的实现以及在解决方案的所有项目中共享的此类事物应该存在于一个名为“YourProject.Shared”的项目中，并且此程序集不得引用任何层：它必须保持层中性，因此在任何地方引用它都不会强迫无用的依赖。

嗯，这是我的观点和工作方式。

Answer 3

如果您不希望其他图层引用数据项目，则必须将IUnitOfWork分隔为单独的项目，并使用依赖注入与一些控制容器的反转。

Answer 4

看看https://github.com/sharparchitecture/Sharp-Architecture它有一个像你一样分层的Northwind示例。您将看到UnitOfWork实现。