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

问题描述

我们正在实施使用EF，WCF和jQuery。

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类专门的服务和用户界面之间传递层之间的数据，但我们有关于使用DTO的方式一些概念问题（发送到用户界面或用户界面接收）。

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:

第一个解决方案（使用POCO除了新手动创建的DTO）

例如假设我们有许多领域的实体。并有一个查找组合框，显示实体记录。我们需要就像组合框的文本字段实体键的组合框的值字段，另一个字段（例如标题）。因此，我们创建一个名为GetAllItemsTitle检索所有的实体法。现在，我们应该回到我们想要的（A键，在这个例子中的值）的结构。因此，我们必须创建一个新类的结构（A键和值）保存它。

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类：

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

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

和方法签名是这样的：

public List<SampleManuallyDto> GetAllItemsTitle()

（使用可空或Emptyable的DTO）解决方案二

我们可以绕过POCO和手动创建的DTO。然后，我们可以定义DTO为可为空或类似的东西可能被认为是空的所有属性（我把它叫做Emptyable）。它使我们能够使用DTO用于多种用途。 Ofcourse，我们需要遵循适配器模式。例如创建一个名为FromEntity，而我们手动创建的DTO转换为EntityObjects（实体框架）ToEntity那些Emptyable DTO的二步法。

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).

现在，我们可以绕过新的DTO类的创作中的第一个解决方案的例子（GetAllItemsTitle）。

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

该方法签名将是这样的：

The method signature will be like this:

public List<SampleDTO> GetAllItemsTitle()

但在方法体中，我们只需填写的ID和SampleDTO的标题属性。正如我所说的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.

结论

通常，第一溶液（使用POCO除了新手动创建的DTO）是Strongy-类型化。它只是可以找出通过看方法签名（有没有额外的属性），每一个方法返回的数据类型。但是，我们有关管理手动创建的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.

更多了，我们面临着这样的问题前pressed例如，当思想促进数据的UI服务。例如，对于更新和插入等此类行动。即使关于搜索规定 - 我们有相同的，选项。

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.

推荐答案

忘记所有关于数据层。创建DTO：■对于每个特定的Web服务调用工作。

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

这不是重要的DTO如何被建立或如何使用它。唯一重要的事情是，他们是如何设计，以尽量减少Web服务调用每个操作的数量。

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的列表：在一个单一的通话S9

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屋！