asp.net-mvc - ASP.NET MVC : What goes where?

Question

我即将开始开发一个中型 ASP.Net MVC 应用程序。
我正在努力使设计正确。我打算有以下几层:

UI 层 (MVC)

服务层

存储层

数据访问层

我将使用 Unity 作为我的 IOC 容器并使用 EF4.1 Code First 进行数据访问。

该应用程序将被拆分为几个程序集。我在决定需要哪些程序集时遇到问题
以及在哪里放置以下内容:

实体/域对象，例如客户，发票

DTO，例如CustomerDTO, InvoiceDTO

服务接口(interface)，例如客服

存储库接口(interface)，例如ICustomerRepository

服务(服务接口(interface)实现类)例如客服

存储库(存储库服务实现类)例如客户资料库

ViewModel 例如客户查看型号

枚举

我的问题是:
你通常如何分割你的，为什么？

编辑:由@TheHurt 的回答提示。

程序集之间的引用如何，即哪个程序集将引用哪个程序集？

Answer 1

这就是我可以解决的方法:

App.UI 程序集:

ViewModels 进入模型区域。

App.Repository 程序集:

具体存储库的抽象实现。

ICustomerRepository

App.Repository.SQL:

具体实现。

EFCF POCO

App.Services 程序集:

抽象服务。

客服

DTO

应用程序服务实现:

具体服务。

客服

应用程序:

共享代码。

枚举

有几个问题我仍然在努力解决。当您跨越服务边界时，您会丢失来自 EFCF 的数据注释。因此，您必须进行服务器端验证，或者您必须使您的 View 模型验证与存储库实体保持同步。感觉越分层的东西越违反DRY。我想这是类(class)的标准，尽管当您的 View 模型不直接映射到您的实体时。你可以让你的 View 模型成为你的 DTO 并将它们扔到 Common 程序集中，但是如果你需要对你的服务 super 灵活的话，这似乎把事情耦合得太紧了。

编辑

如果您想将 WCF 集成到混合中，您可能希望创建非常接近 MVC View 模型的数据协定(或将协定用作 View 模型)。您可能不会向世界公开它，因为该服务将特定于您的 MVC 站点的实现，启动另一个服务以供公众使用。如果您正在执行 WCF 服务，您可能希望在服务中包含所有业务逻辑， Controller 将只处理导航逻辑。

旁注，我尽量远离“金属”，同时开发一种允许我将来将代码分成不同层的设计。如果我不能用一张纸向我的经理清楚地解释各个系统层，那么设计很可能过于复杂。如果设计得当，大部分内容在 Visio 中都会看起来很漂亮。

至于事物如何相互引用:UI 将引用 Serivce(或服务实现，可能不需要。只需将它们都放在同一个地方。)。服务引用存储库。存储库实现没有任何引用，因为它是由 IOC 加载的。一切都引用通用。