WCF数据合同和参考实体数据？ [英] WCF Data Contract and Reference Entity Data?

问题描述

参考数据是什么意思？

>

我们以Northwind为例。订单与数据库中的客户相关。当我实现我的订单服务时，在某些情况下，我希望引用一个完整的客户从一个订单和其他情况下，我只想要一个引用客户（例如一个键/值对）。

例如，如果我正在做一个GetAllOrders（），我不想要返回一个完全填写的订单，我想要返回一个轻量级版本一个订单，只有每个订单的客户的参考数据。如果我做了一个GetOrder（）方法，我可能想填写客户的详细信息，因为这个方法的消费者可能需要它。可能还有其他情况，我可能会要求客户的详细信息在某些方法调用期间填写，但不允许其他人使用。

这是我想出的：

  DataContract] 
 public OrderDTO 
 {
 [DataMember（必需）] 
 public CustomerDTO; 
 
 // etc .. 
} 
 
 [DataContract] 
 public CustomerDTO 
 {
 [DataMember（Required）] 
 public ReferenceInfo ReferenceInfo; 
 
 [DataMember（可选）] 
 public CustomerInfo CustomerInfo; 
} 
 
 [DataContract] 
 public ReferenceInfo 
 {
 [DataMember（必需）] 
 public string Key; 
 
 [DataMember（Required）] 
 public string Value; 
} 
 
 [DataContract] 
 public CustomerInfo 
 {
 [DataMember（必需）] 
 public string CustomerID; 
 
 [DataMember（Required）] 
 public string Name; 
 
 // etc .... 
} 
  

在这里思考的是，由于在CustomerDTO中始终需要ReferenceInfo（它是一个通用的键/值对），所以我将始终有ReferenceInfo。如果需要，它给我足够的信息以获得客户的细节。让CustomerDTO需要ReferenceInfo的缺点是，当我收到完整的CustomerDTO（即填写CustomerInfo）时可能会过度，但至少我保证参考信息。

还有其他一些模式或框架，我可以用来使这个场景/实现更干净吗？

我问的原因是，尽管我们可以在Northwind简单地说，总是返回一个完整的CustomerDTO，这可能在简化的Northwind情况下可以正常工作。在我的情况下，我有一个对象有25-50个字段是引用/查找类型数据。有些在不同情况下比其他人更重要，但我想尽可能少的定义这些引用类型（这样我就不会进入DTO维护地狱）。

意见？反馈？评论？

谢谢！

解决方案

Amazon产品广告API Web服务是您遇到的同样问题的一个很好的例子。

他们使用不同的DTO根据具体情况向呼叫者提供更多或更少的细节。例如，小响应组，大型响应组并在中间中度响应组。

如果你说你不想要一个聊天界面，拥有不同的DTO是一个很好的技术。

Soliciting feedback/options/comments regarding a "best" pattern to use for reference data in my services.

What do I mean by reference data?

Let's use Northwind as an example. An Order is related to a Customer in the database. When I implement my Orders Service, in some cases I'll want the reference a "full" Customer from an Order and other cases when I just want a reference to the Customer (for example a Key/Value pair).

For example, if I were doing a GetAllOrders(), I wouldn't want to return a fully filled out Order, I'd want to return a lightweight version of an Order with only reference data for each order's Customer. If I did a GetOrder() method, though, I'd probably want to fill in the Customer details because chances are a consumer of this method might need it. There might be other situations where I might want to ask that the Customer details be filled in during certain method calls, but left out for others.

Here is what I've come up with:

[DataContract]
public OrderDTO
{
    [DataMember(Required)]
    public CustomerDTO;

    //etc..
}

[DataContract]
public CustomerDTO
{
    [DataMember(Required)]
    public ReferenceInfo ReferenceInfo;

    [DataMember(Optional)]
    public CustomerInfo CustomerInfo;
}

[DataContract]
public ReferenceInfo
{
    [DataMember(Required)]
    public string Key;

    [DataMember(Required)]
    public string Value;
}

[DataContract]
public CustomerInfo 
{
    [DataMember(Required)]
    public string CustomerID;

    [DataMember(Required)]
    public string Name;

    //etc....
}

The thinking here is that since ReferenceInfo (which is a generic Key/Value pair) is always required in CustomerDTO, I'll always have ReferenceInfo. It gives me enough information to obtain the Customer details later if needed. The downside to having CustomerDTO require ReferenceInfo is that it might be overkill when I am getting the full CustomerDTO (i.e. with CustomerInfo filled in), but at least I am guaranteed the reference info.

Is there some other pattern or framework piece I can use to make this scenario/implementation "cleaner"?

The reason I ask is that although we could simply say in Northwind to ALWAYS return a full CustomerDTO, that might work fine in the simplistic Northwind situation. In my case, I have an object that has 25-50 fields that are reference/lookup type data. Some are more important to load than others in different situations, but i'd like to have as few definitions of these reference types as possible (so that I don't get into "DTO maintenance hell").

Opinions? Feedback? Comments?

Thanks!

解决方案

Amazon Product Advertising API Web service is a good example of the same problem that you are experiencing.

They use different DTOs to provide callers with more or less detail depending on their circumstances. For example there is the small response group, the large response group and in the middle medium response group.

Having different DTOs is a good technique if as you say you don't want a chatty interface.

这篇关于WCF数据合同和参考实体数据？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！