在 SOA 应用程序中使用 DTO 的最佳方式是什么? [英] What is the best way of using DTOs in a SOA application?

问题描述

我们正在使用 EF、WCF 和 jQuery 实现 SOA Web 应用程序.

We are implementing a SOA web application using EF, WCF and jQuery.

以下是我们的架构简介:

Here is our architecture in a brief view:

-------------   ---
|    UI     |  |   |
-------------  |   |
| Services  |  | D |
-------------  | T |
| Businsess |  | O |
-------------  |   |
|    Dal    |  |   |
-------------   ---

我们知道我们应该有 DTO 类来在层之间传递数据，特别是在服务和 UI 之间，但是我们对使用 DTO 的方式(发送到 UI 或从 UI 接收)有一些概念上的问题.

We know that we should have DTO classes to pass data between the layers specially between the Services and the UI but We have some conceptual issues about the way of using DTOs (to send to the UI or receive from UI).

对于数据驱动项目，我们可以使用 POCO 自动生成 DTO 对象.但在大型应用程序中，它并没有那么简单.

For Data-Driven project we can use POCO to generate the DTO objects automaticly. But in big applications it's not that simple.

我们知道有两种解决方案可以解决我们的问题:

We know two solutions to solve our issue:

第一个解决方案(除了新的手动创建的 DTO 之外还使用 POCO)

例如假设我们有一个包含许多字段的实体.还有一个显示实体记录的查找组合框.我们只需要一个实体键作为组合框值字段和另一个字段(例如标题)作为组合框文本字段.所以我们创建了一个名为GetAllItemsTitle"的方法来检索所有实体.现在我们应该只返回我们想要的结构(在这个例子中是一个键和一个值).所以我们必须创建一个新类来在其中存储该结构(一个键和一个值).

For example suppose that we have an entity with many fields. And there is a lookup combobox that shows the entity records. We need just an entity key as the combobox value field and another field (for example Title) as the combobox text field. So we create a method named "GetAllItemsTitle" to retrieve all entities. Now we should just return the structure which we want (A key and a value in this example). So we have to create a new class to store that structure (A key and a value) in it.

这将是新的 DTO 类:

This will be the new DTO class:

[DataContract]
public class SampleManuallyDto
{
    [DataMember]
    public long Id { get; set; }

    [DataMember]
    public string Title { get; set; }
}

而且方法签名是这样的:

And the method signature is like this:

public List<SampleManuallyDto> GetAllItemsTitle()

第二种解决方案(使用 Nullable 或 Emptyable DTO)

我们可以绕过 POCO 并手动创建 DTO.然后我们可以将 DTO 的所有属性定义为可为空的或类似可以识别为 Empty(我称之为 Emptyable)的属性.它允许我们将 DTO 用于多种目的.当然我们需要遵循适配器模式.例如，为那些名为FromEntity"和ToEntity"的 Emptyable DTO 创建两个方法，将我们手动创建的 DTO 转换为(实体框架的)EntityObjects.

We can bypass the POCO and create DTOs manually. Then we may define all properties of the DTO as nullable or something like that which could be recognized as Empty (I called it Emptyable). It allows us to use a DTO for several purposes. Ofcourse we need to follow the Adapter pattern. For example create two method for those Emptyable DTOs named "FromEntity" and "ToEntity" that converts our manually created DTOs to EntityObjects (of entity framework).

现在我们可以绕过在第一个解决方案"(GetAllItemsTitle)示例中创建新的 DTO 类.

Now we can bypass the creation of a new DTO classes in the example of the "first solution" (GetAllItemsTitle).

方法签名如下:

public List<SampleDTO> GetAllItemsTitle()

但在方法体中，我们只填写 SampleDTO 的Id"和Title"属性.正如我所说，SampleDTO 的所有属性都可以为空，所以我们只填充我们想要的那些，而其他的则留空.

But in the method body we just fill the "Id" and "Title" properties of the SampleDTO. As I said all properties of the SampleDTO can be empty so we just fill those we want and leave the others empty.

结论

通常，第一个解决方案(除了新的手动创建的 DTO 之外还使用 POCO)是 Strongy-Typed.只需查看方法签名即可找出每个方法返回的数据类型(没有额外的属性).但是我们担心管理手动创建的 DTO.他们很快就会长大.

Generally, the first solution (using POCO besides the new manually created DTOs) is Strongy-Typed. It's simply possible to find out each method return data type by just looking at the method signature (there is no extra properties). But we are worry about managing manually created DTOs. They will grow up soon.

但第二种解决方案是一种更动态的方法，识别将从GetAllItemsTitle"返回的内容的唯一方法是查看方法主体或其文档.所以我们担心运行时错误".开发人员可能会假设一个属性不应该在它为空时为空.

But the second solution is a more dynamic way and the only way to recognize what will be returned from the "GetAllItemsTitle" is looking at the method body or its documentation. So we are worry about "Runtime Errors". Developers may suppose that a property should not be empty while it is empty.

此外，我们在将数据从用户界面放置"到服务时遇到的此类问题的表达示例.例如用于更新和插入等操作.即使是关于搜索标准"，我们也有相同的选择.

More over, the expressed example we faced to such issue when "Puting" data from UI to Services. For example for Update and Insert and other such action. Even about the "Search Criterias" we have the same choises.

抱歉问了这么长的问题.请帮助我们提供您的善意建议.

Sorry for the long question. Please help us with your kindly advices.

推荐答案

忘记所有关于数据层的事情.创建适用于每个特定 Web 服务调用的 DTO:s.

Forget all about the data layer. Create DTO:s that works for each specific web service call.

DTO 的构建方式或使用方式并不重要.唯一重要的是它们的设计如何最大限度地减少每个操作的网络服务调用量.

It's not important how the DTO is built or how it's used. The only thing that matters is how they are designed to minimize the amount of webservice calls for each operation.

例如:假设您有一个用例，您需要遍历所有用户以修改他们的地址.如果您首先需要获取所有用户，然后为每个用户进行 Web 服务调用以获取其地址，那么糟糕的设计将是一个糟糕的设计.一个正确的设计是在一次调用中返回一个 UserWithAddress DTO:s 列表.

For instance: Let's say that you have a use case where you need to traverse all users to to modify their addresses. A bad design would be if you first need to fetch all users and then make a webservice call for each user to fetch it's address. A proper design would be to return a list of UserWithAddress DTO:s in a single call.

这篇关于在 SOA 应用程序中使用 DTO 的最佳方式是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！