应用程序级别应该包含实施 DTO
最近，我听到了很多关于 DTOs 他们有多有用，但我找不到他们在上下文中使用的一个很好的例子 ASP.NET.
假设我使用三级架构：
数据级别/使用 Entity Framework/
商业水平 /WCF 服务/
演示水平 /MVC 4.0 Web应用程序/
我必须转换一个对象 EF Employee 在 EmployeeDTO POCO?
假设我在对数据的访问级别执行转换，但服务中会发生什么 WCF? 然后他应该转换为另一个对象吗？
, 当他落到水平时 UI /Web应用程序 MVC/, 他应该在模特中的第三次转变吗？ 如果有人可以为我澄清它，我会感激
假设我使用三级架构：
数据级别/使用 Entity Framework/
商业水平 /WCF 服务/
演示水平 /MVC 4.0 Web应用程序/
我必须转换一个对象 EF Employee 在 EmployeeDTO POCO?
假设我在对数据的访问级别执行转换，但服务中会发生什么 WCF? 然后他应该转换为另一个对象吗？
DataMember
, 当他落到水平时 UI /Web应用程序 MVC/, 他应该在模特中的第三次转变吗？ 如果有人可以为我澄清它，我会感激
没有找到相关结果
已邀请:
6 个回复
冰洋
赞同来自:
这是您服务级别的业务水平的责任。 / 数据级别并创建您提供外部世界的DTO-E。
您在业务和数据级别中使用的内容取决于架构。 您可能有一个域模型，它首先与代码相比。 在这种情况下，服务级别将域实体与数据合同进行比较 /DTO/. 如果您没有域模型 /贫血模型/, 然后您可以简单地将数据库与您的数据库进行比较 DTO.
网站 ASP.NET MVC 消耗服务并比较结果 DTO 使用专用表示模型，然后将其传输到特定的表示。
此外，还可以决定将请求划分为命令。 这是一种很好的方法，因为 DTO, 您将其作为查询结果返回，与您发送给服务的命令完全不同。 该命令仅包含执行命令所需的内容，并包含要实现的业务意图，而请求返回您需要的平滑模型 UI.
其他的建议：
不要透露数据库的本质。
不要转换为业务层，因为这不是业务逻辑。
裸奔
赞同来自:
核
, 所有人都知道这一点。 所以你有了
Core
|
------------
| | |
DAL BL PL
每层都可以使用
. 每层也展示
野人奥卡夫。 API. 但内部，每层都可以转换 / 适应
, 例如，您从数据库中读取
然后将它转换为
. 转型包含在图层边界处。
例如，如果您有几种不同的模型，则为所有层中的相同件相同的东西 PL 愿意
和 DAL 效劳于
, 你最终会变得一团糟。
小姐请别说爱
赞同来自:
, 在此处添加，因为我的声誉不足以添加评论。
就个人而言，我会给 entitys 在您的持久性和您的业务水平之间。 在你使用时 MVC, 最有可能的是，您将向控制器传输查看模型。 此刻我会用你的演示模型比较你的演示模型 DTOs /s/.
如果您打算使用 DTO 在所有图层之间，然后创建一个跨切割项目，然后可以引用。
石油百科
赞同来自:
Shared
对于这样的目的，特别是与所有层共享对象。 无论名称如何，它都应该与所有层都可见。
窦买办
赞同来自:
设想：
您的演示水平导致您的业务水平通过 DTO. 你执行一些逻辑检查 &, 然后转换 DTO 实质上并将其发送到您的数据访问级别。
IE
UI -- > 胎。 层 /转变为本质/ -- > 数据层
我喜欢这种方法，因为我认为数据级别不应有任何转换逻辑，并且应根据需要接收和处理实体。 它是有效的另一个原因，现在您可以定义特定的业务规则。 / 转换过程中的验证逻辑在将其发送到数据级别之前。
这是旧的
https://msdn.microsoft.com/en- ... .aspx
MSDN, 但它有几个精彩的细节，解释了这种方法。
八刀丁二
赞同来自:
EF 合作 Poco, 他们可以序列化 WCF.
它们必须定义 assembly, 所有项目都参考。
在 ASP.NET MVC 你会搬到 ViewModel, 使用 Poco-DTO.