我想让设计正确.我打算有以下几层：
> UI层(MVC)
>服务层
>存储库层
>数据访问层
我将使用Unity作为我的IOC容器,使用EF4.1 Code First进行数据访问.
该应用程序将拆分为几个程序集.我在确定需要哪些组件时遇到问题
以及如何放置以下内容：
>实体/域对象,例如客户,发票
> DTO,例如CustomerDTO,InvoiceDTO
>服务接口,例如ICustomerService
>存储库接口,例如ICustomerRepository
>服务(服务接口实现类),例如客户服务
>存储库(存储库服务实现类),例如CustomerRepository
> viewmodels例如Customerviewmodel
>枚举
我的问题是：
你通常如何拆分你的？为什么？
编辑：由@TheHurt的回答提示.
如何在组件之间引用,即哪个组件将引用哪个组件？
解决方法
App.UI程序集：
> viewmodels进入模型区域.
App.Repository程序集：
>具体存储库的抽象实现.
> ICustomerRepository
App.Repository.sql：
>具体实施.
> EFCF POCO
App.Services组装：
>抽象服务.
> ICustomerService
> DTO
App.Services.Implementation：
>具体服务.
>客户服务
App.Common：
>共享代码.
>枚举
有几个问题我还在努力解决.当您跨越服务边界时,您将丢失来自EFCF的数据注释.因此,您必须进行服务器端验证,或者必须使视图模型验证与存储库实体保持同步.感觉层次越多,DRY就越多.虽然当你的视图模型没有直接映射到你的实体时,我认为这是课程的标准.您可以将您的视图模型作为您的DTO并将它们放入Common程序集中,但如果您需要对服务具有超级灵活性,那么这似乎会过于紧密.
编辑
如果您想要将WCF集成到混合中,您可能希望创建非常接近MVC视图模型的数据协定(或使用契约作为视图模型).您可能不会向全世界公开,因为该服务将特定于您的MVC站点的实现,为了公共消费而启动另一项服务.如果您正在进行WCF服务,您可能希望在服务中拥有所有业务逻辑,控制器将只处理导航逻辑.
旁注,我试图尽可能远离“金属”,同时开发一种设计,允许我将代码分成不同的层次.如果我不能用一张纸清楚地向我的经理解释各种系统层,那么设计很可能太复杂了.如果设计得很好,大部分内容都会在Visio中看起来很漂亮.
至于事物如何相互引用：UI将引用Serivce(或服务实现,这可能不需要.只需将它们保存在同一个地方.).服务引用存储库.存储库实现没有任何内容,因为它是由IOC加载的.一切都是常见的.
