ASP.NET MVC：什么放在哪里？

Question

ASP.NET MVC：什么放在哪里？

asp.net-mvcrepository-pattern

8

我将要开发一个中等规模的ASP.Net MVC应用程序。我正在努力确保设计正确。我打算有以下层：

- UI层（MVC） - Service层 - Repository层 - 数据访问层

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

该应用程序将被拆分成几个程序集。我有一个问题，无法决定我将需要哪些程序集以及以下内容放在何处：

- 实体/域对象，例如Customer、Invoice - DTO，例如CustomerDTO、InvoiceDTO - 服务接口，例如ICustomerService - 存储库接口，例如ICustomerRepository - 服务(Service接口实现类)，例如CustomerService - 存储库（存储库服务实现类），例如CustomerRepository - 视图模型，例如CustomerViewModel - 枚举

我的问题是：您通常如何分割您的程序集，以及为什么？

编辑：受@TheHurt答案的启发。

这些程序集之间的引用将是如何的？也就是说，哪个程序集会引用哪个程序集？

- Gichamba

你需要DTO吗？为什么不能使用EFCF POCOs？ - TheHurt

@TheHurt：并不是所有实体都需要 DTO，但对于某些实体来说，视图所需的内容与实际存储在数据库中的内容非常不同。 - Gichamba

1

我认为DTO仍然有用，因为有时你只想传递一些属性。我不喜欢传递只设置了几个属性（其他所有属性都设置为默认值）的实体，因为这可能有点危险。 - Lee Gunn

DTO（数据传输对象）非常方便，可以在控制器和处理业务逻辑的任何类型层之间封装数据。它清晰地将控制器与应用程序分离开来。您不希望将实体的行为暴露给控制器。 - David Neale

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- TheHurt · Accepted Answer

这是我处理它的方式：

App.UI组件： - ViewModel放在Models区域。

App.Repository组件： - 具体存储库的抽象实现。 - ICustomerRepository

App.Repository.SQL组件： - 具体实现。 - EFCF POCOs

App.Services组件： - 抽象服务。 - ICustomerService - DTOs

App.Services.Implementation组件： - 具体服务。 - CustomerService App.Common组件： - 共享代码。 - 枚举

还有一些问题我仍然很困扰。当您跨服务边界时，您会失去EFCF的数据注释。因此，您必须进行服务器端验证，或者您必须使您的视图模型验证与存储库实体保持同步。感觉分层越多，DRY原则就会被违反得越厉害。我想这是理所当然的，因为您的视图模型不能直接映射到您的实体。您可以将视图模型作为DTO，并将它们放入Common组件中，但如果您需要对服务非常灵活，则似乎这样耦合的事情太紧了。

编辑：如果您想将WCF集成到混合中，您可能希望创建数据合同，这些合同非常接近MVC视图模型（或将合同用作视图模型）。您可能不希望将其公开给世界，因为服务将针对MVC站点的该实现，为公共使用启动另一个服务。如果您正在执行WCF服务，则可能希望在服务中拥有所有业务逻辑，控制器只处理导航逻辑。

顺便说一句，我尽可能地远离“金属”，同时开发出一种设计，使我能够将代码分离成各个层。如果我无法用一张纸清楚地解释各个系统层给我的经理，那么这个设计很可能过于复杂。如果设计得好，大多数情况下，Visio中的所有内容都看起来很漂亮。

至于如何相互引用：UI将引用Serivce（或服务实现，可能不需要。只需将其全部放在同一位置即可）。服务引用存储库。存储库实现不引用任何内容，因为它由IOC加载。所有内容都引用Common组件。