Контракт данных WCF и ссылочные данные объекта?

Мне это кажется сложным решением. Почему бы просто не создать поле идентификатора клиента в классе OrderDTO, а затем позволить приложению решать во время выполнения, нужны ли ему данные клиента. Так как у него есть идентификатор клиента, он может вытащить данные, когда захочет.

I've decided against the approach I was going to take. I think much of my initial concerns were a result of a lack of requirements. I sort of expected this to be the case, but was curious to see how others might have tackled this issue of determining when to load up certain data and when not to.

I am flattening my Data Contract to contain the most used fields of reference data elements. This should work for a majority of consumers. If the supplied data is not enough for a given consumer, they'll have the option to query a separate service to pull back the full details for a particular reference entity (for example a Currency, State, etc). For simple lookups that really are basically Key/Value pairs, we'll be handling them with a generic Key/Value pair Data Contract. I might even use the KnownType attribute for my more specialized Key/Value pairs.

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

    //in this case, I think consumers will need currency data, 
    //so I pass back a full currency item
    [DataMember(Required)]
    public Currency Currency; 

    //in this case, I think consumers are not likely to need full StateRegion data, 
    //so I pass back a "reference" to it
    //User's can call a separate service method to get full details if needed, or 
    [DataMember(Required)]
    public KeyValuePair ShipToStateRegion;

    //etc..
}


[DataContract]
[KnownType(Currency)]
public KeyValuePair
{
    [DataMember(Required)]
    public string Key;

    [DataMember(Required)]
    public string Value;

    //enum consisting of all possible reference types, 
    //such as "Currency", "StateRegion", "Country", etc.
    [DataMember(Required)]
    public ReferenceType ReferenceType; 
}


[DataContract]
public Currency : KeyValuePair
{
    [DataMember(Required)]
    public decimal ExchangeRate;

    [DataMember(Required)]
    public DateTime ExchangeRateAsOfDate;
}


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

    [DataMember(Required)]
    public string Name;

    //etc....
}

Thoughts? Opinions? Comments?

Мы столкнулись с этой проблемой и в объектно-реляционном отображении. Есть ситуации, когда нам нужен полный объект, а в других - ссылка на него.

Трудность состоит в том, что, запекая сериализацию в самих классах, шаблон контракта данных навязывает идею о том, что существует только один правильный путь. для сериализации объекта. Но существует множество сценариев, в которых вы можете захотеть частично сериализовать класс и / или его дочерние объекты.

Обычно это означает, что вам нужно иметь несколько DTO для каждого класса. Например, FullCustomerDTO и CustomerReferenceDTO. Затем вам нужно создать способы сопоставления различных DTO с объектом домена Customer.

Как вы можете себе представить, это тонна работы, большая часть которой очень утомительна.

Мы находимся на той же стадии принятия решения по нашему проекту. На данный момент мы решили создать три уровня DTO для обработки Вещи: SimpleThing, ComplexThing и FullThing. Однако мы не знаем, как это сработает для нас, так что это еще не ответ, основанный на реальности.

Мне интересно только одно: узнаем ли мы, что наши сервисы спроектированы «неправильно». "уровень. Например, есть ли когда-нибудь случай, когда мы должны разобрать FullThing и передать только SimpleThing? Если да, значит ли это, что мы неуместно поставили бизнес-логику на слишком высокий уровень?

Еще одна возможность - рассматривать объекты как мешки с собственностью. Укажите свойства, которые вы хотите, при запросе, и верните именно те свойства, которые вам нужны.

Изменение свойств, отображаемых в «короткой» версии, не потребует многократных обходов, вы можете получить все свойства для набора за один раз (избегая болтливых интерфейсов), и вам не нужно изменять свои данные или контракты операций, если вы решите, что вам нужны другие свойства для «короткой» версии.

Веб-сервис Amazon Product Advertising API является хорошим примером той же проблемы, с которой вы столкнулись.

Они используют разные DTO, чтобы предоставить вызывающим абонентам более или менее подробную информацию в зависимости от их обстоятельств. Например, есть малая группа ответа , большая группа ответа и средняя группа ответа .

Наличие разных DTO - хороший метод, если как вы говорите, вам не нужен болтливый интерфейс.

Я обычно встраиваю отложенную загрузку в свои сложные веб-службы (т. Е. Веб-службы, которые отправляют / получают объекты). Если у Person есть свойство Father (также Person), я отправляю только идентификатор для отца вместо вложенного объекта, тогда я просто проверяю, что моя веб-служба имеет операцию, которая может принимать идентификатор и отвечать соответствующей сущностью Person. . Затем клиент может вызвать веб-службу обратно, если он хочет использовать свойство «Отец».

Я также расширил это, чтобы можно было выполнять пакетную обработку. Если операция отправляет обратно 5 лиц, то при доступе к свойству «Отец» для любого из этих лиц выполняется запрос для всех 5 отцов с их идентификаторами. Это помогает снизить болтовню веб-службы.