DTO和Domain Object、WCF以及DB层交互答案

【问题标题】：DTO and Domain Object, WCF as well as DB Layer interactionDTO和Domain Object、WCF以及DB层交互
【发布时间】：2012-09-08 10:05:38
【问题描述】：

我有 asp.net mvc 2 应用程序。我在创建 DTO 和域实体时感到困惑。

MVC 控制器集成点： 1) 第三方 WCF 2) 数据库层

WCF 正在返回特定公司的人员信息和有关公司的一些信息。

我已经生成了 WCF 的代理并在代理上编写了一个服务包装器。服务包装器正在与 WCF 对话并将结果映射到 DTO 类 ContactsDTO 服务层在不同的项目中。

以下是我的域类

Company
Person

DTO class
//it contains
class ContactsDTO
{
Person person, Company[] company
}

控制器动作调用带有 companyID 的包装器并获取 DTO 类的对象。并从 dto 更新公司信息。它更新 Session 中的公司信息，并将 Company[]array 传递给其他一些操作。

数据库交互：

现在根据一些业务逻辑，我必须在数据库中插入人员 ID 和公司 ID 以及其他一些信息。

为此我创建了另一个

class DBDTO
{
Person person, Company[] company, OtherInfo otherInfo[]

}

此 DBDTO 已准备好并传递给 DB 层（使用 Linq to sql）。

问题

是写方式吗。 DTO交互有什么改进吗？什么都我可以做一些改变来改善整体架构

【问题讨论】：

DTO，正如其名称中所述，是数据传输对象。它应该只用于传输，不应该封装域对象，也不应该封装数据库对象。也就是说，您的 DB 层可能有一些特定的对象，例如 DBObject，它们直接从/到 DTO 映射，而客户端的 DTO 直接从/到客户端对象（例如 ClientEntity）映射。有很多基础架构代码和映射，是的，但最终您将拥有干净、独立的客户端和 DB 层域对象代码。

【解决方案1】：

我同意 Algirdas 因职责不同而区分模型。

顺便说一句：MVC 不是层概念。这是三个责任及其协作的概念。虽然它经常（误）用于分层，但如果您只使用“MVC”分离应用程序层，您将遇到 SRP 问题。如果你每层都有 MVC，那么你就很好了。

毕竟，如果它是一个小型应用程序，您可能永远无法达到临界质量，从而遇到架构问题。

【讨论】：

【解决方案2】：

另一个将 DB 绑定对象转换为 DTO（这需要时间）的替代方法是使用 POCO（普通旧 CLR 对象）并将它们直接用作您的域模型，可以存储在 DB 中的对象和可以存储在数据库中的对象传达给控制器进行可视化。这可以让你开始：Working with POCO Entities

这种方法有几个优点

您的 POCO 实体独立于底层数据库实现
您的 POCO 实体可以在不存在数据库的情况下进行单元测试
您可以使用DataContractSerializer 或DataContractJsonSerializer 轻松地将它们序列化为服务响应（如果您正在构建API）

【讨论】：