我(重新)设计大规模应用程序,我们使用基于DDD的多层架构.
我们有MVC与数据层(存储库的实现),域层(域模型的定义和接口 - 存储库,服务,工作单元),服务层(服务的实现).到目前为止,我们使用跨所有层的域模型(主要是实体),并且我们仅将DTO用作视图模型(在控制器中,服务返回域模型,并且控制器创建视图模型,其被传递到视图).
我读过很多关于使用,而不是使用,映射和传递DTO的文章.我知道没有任何确定的答案,但我不确定是否可以将域模型从服务返回到控制器.如果我返回域模型,它仍然永远不会传递给视图,因为控制器总是创建特定于视图的视图模型 - 在这种情况下,它似乎是合法的.另一方面,当域模型离开业务层(服务层)时感觉不对.有时服务需要返回域中未定义的数据对象,然后我们要么必须将新对象添加到未映射的域,要么创建POCO对象(这很丑陋,因为有些服务返回域模型,有些有效地返回DTO).
问题是 - 如果我们严格使用视图模型,是否可以将域模型一直返回到控制器,或者我们是否应该始终使用DTO与服务层进行通信？如果是这样,根据需要的服务调整域模型是否可以？(坦率地说,我不这么认为,因为服务应该消耗域名所具有的.)如果我们应该严格遵守DTO,它们应该在服务层中定义吗？(我想是的.)有时很明显我们应该使用DTO(例如,当服务执行大量业务逻辑并创建新对象时),有时很明显我们应该只使用域模型(例如,当成员服务返回贫血用户时( s) - 创建与域模型相同的DTO似乎没有多大意义) - 但我更喜欢一致性和良好实践.
Article Domain vs DTO vs ViewModel - 如何以及何时使用它们？(以及其他一些文章)与我的问题非常相似,但它没有回答这个问题.文章我应该用EF在存储库模式中实现DTO吗？也是类似的,但它不涉及DDD.
免责声明:我不打算只使用任何设计模式,因为它存在且很花哨,另一方面,我也想使用良好的设计模式和实践,因为它有助于设计整个应用程序,有助于分离至少在目前,即使是使用特定模式进行处理也不是"必要的".
一如既往,谢谢.
architecture asp.net-mvc domain-driven-design entity-framework