ASP.NET MVC:什么在哪里？

Question

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

• UI层(MVC)
• 服务层
• 存储库层
• 数据访问层

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

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

• 实体/域对象,例如客户,发票
• DTO,例如CustomerDTO,InvoiceDTO
• 服务接口,例如ICustomerService
• 存储库接口,例如ICustomerRepository
• 服务(服务接口实现类),例如CustomerService
• 存储库(存储库服务实现类),例如CustomerRepository
• ViewModels例如CustomerViewModel
• 枚举

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

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

如何在组件之间引用,即哪个组件将引用哪个组件？

Answer 1

这就是我可能解决的方法：

应用程序UI组件：

• ViewModels 位于模型区域。

应用程序存储库组件：

• 具体存储库的抽象实现。
• 客户信息库

应用程序存储库.SQL：

• 具体实施。
• EFCF POCO

应用程序服务组装：

• 抽象服务。
• 客户服务部
• DTO

应用程序服务实施：

• 具体服务。
• 客户服务

应用程序通用：

• 共享代码。
• 枚举

有几个问题我仍然在努力解决。当您跨越服务边界时，您会丢失来自 EFCF 的数据注释。因此，您必须进行服务器端验证，或者必须使视图模型验证与存储库实体保持同步。感觉越是有层次的东西，越是违反了DRY。我认为当您的视图模型不直接映射到您的实体时，这对于课程来说是正常的。您可以将视图模型作为 DTO，并将它们放入 Common 程序集中，但如果您需要对服务进行超级灵活，那么这似乎将事情耦合得太紧密。

编辑

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

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

至于事物如何相互引用：UI 将引用 Serivce（或服务实现，这可能不需要。只需将其全部放在同一个位置即可。）。服务引用存储库。存储库实现不引用任何内容，因为它是由 IOC 加载的。一切都参考通用。