最近我已经听过很多关于DTO的信息以及它们的用处,但我找不到在ASP.NET环境中使用它的好例子。
我们说我使用三层架构:
我应该从EF Employee对象转换为EmployeeDTO POCO?
让我说我在数据访问层进行转换但是在WCF服务中会发生什么?它是否应该转换为另一个DataMember
对象,当它到达UI层(MVC Web应用程序)时,它是否应该第三次转换为模型?如果有人能为我清楚这件事,我将不胜感激
答案 0 :(得分:8)
您的服务层公开了DTO。这意味着在服务层中,您可以按照您希望它们向外界公开的方式定义数据协定。在大多数情况下,它们是扁平实体,不一定与数据库实体具有相同的结构。
您的服务层有责任使用业务/数据层并构建您向外界公开的DTO。
您在业务和数据层中使用的内容取决于体系结构。您可以拥有一个首先使用代码映射的域模型。在这种情况下,服务层将域实体映射到数据协定(DTO' s)。如果您没有域模型(贫血模型),那么您也可以直接将数据库映射到您的DTO。
ASP.NET MVC站点使用该服务,并将其收到的DTO映射到专用视图模型,然后传递给特定视图。
此外,您可能还决定从命令中拆分查询。这是一种很好的方法,因为您作为查询请求获得的DTO与您发送给服务的命令完全不同。命令仅包含执行命令所需的内容,并包含业务意图您想要实现的内容,而查询则返回UI中所需内容的展平模型。
其他评论:
答案 1 :(得分:7)
在类似的情况下,我曾经将dto放入 Core 中,这三者都是已知的。你有
Core | ------------ | | | DAL BL PL
每个图层都可以使用Core.Dto.Employee
进行操作。每个图层还在其API中向外部公开Core.Dto.Employee
。但内部每个层都可以转换/调整Core.Dto.Employee
,例如您从数据库EF.Employee
读取,然后将其转换为Core.Dto.Employee
。转换包含在图层的边界内。
如果您有多个不同的模型在整个层中表示相同的事物,例如PL想要PL.Employee
而DAL在EF.Employee
上操作,那么最终会出现问题。
答案 2 :(得分:3)
请查看此处添加的https://stackoverflow.com/a/6310507/1771365,因为我没有足够的声誉来添加评论。
我个人会在你的持久层和你的业务层之间传递实体。当您使用MVC时,您可以将视图模型传递给控制器。此时,我会将您的视图模型映射到您的DTO。
如果您打算在所有图层之间使用DTO,请创建一个交叉项目,然后您可以参考该项目。
答案 3 :(得分:1)
我特别喜欢的方法是在商务层中进行DTO转换。
场景:您的演示层呼叫您的业务层传递DTO。你做了一些逻辑和验证,然后将DTO转换为实体并将其发送到您的数据访问层。
即。 用户界面 - >总线。图层(转换为实体) - >数据层
我喜欢这种方法,因为我认为数据层不应该有任何转换逻辑,应该根据需要接收和处理实体。此有效的另一个原因是您现在可以在转换过程中定义特定的业务规则/验证逻辑,然后再将其发送到数据层。 这是一个古老的MSDN article,但有一些很好的细节解释了类似的方法。
答案 4 :(得分:1)
我使用名为共享的项目用于此类目的,特别是与所有图层共享对象。无论名称如何,所有图层都应该可以看到它。
答案 5 :(得分:-2)
不应该有任何转换。你只需使用Poco Objects作为DTO。
EF与Poco合作,它们可以由WCF序列化。
它们应该在所有项目引用的程序集中定义。
在ASP.NET MVC中,您可以使用Poco-DTO映射到ViewModel。