Как организовать и назвать DTO, которые используются в качестве контрактов данных в веб-службе WCF

Мы используем DTO в качестве контрактов данных в нашем веб-сервисе WCF. Целью этих DTO является предоставление только той информации, которая имеет отношение к конкретному методу API.

Что я ищу от вас, ребята, так это несколько советов о лучших практиках здесь.

Например, рассмотрим следующую простую модель:

class Order
{
    int CreatedBy { get; set; }
    DateTime CreatedOn { get; set; }
    string Description { get; set; }
    int Id { get; set; }
    string Name { get; set; }
}

Предполагая, что наш API позволяет потребителю создать , обновить и получить заказ, мы создали следующие DTO. Атрибуты DataMember и DataContract исключены для простоты.

Создать метод :Пользователь не может указать свойства Id и CreatedOn , поэтому DTO выглядит так:

class CreateOrderData
{
    int CreatedBy { get; set; }
    string Description { get; set; }
    string Name { get; set; }
}

Обновление метода :Пользователь не может указать свойства Id , CreatedOn и CreatedBy , поэтому DTO выглядит так:

class UpdateOrderData
{
    string Description { get; set; }
    string Name { get; set; }
}

Получить метод :Пользователь должен иметь возможность видеть все для Заказа, поэтому DTO выглядит так:

class OrderData
{
    int CreatedBy { get; set; }
    DateTime CreatedOn { get; set; }
    string Description { get; set; }
    int Id { get; set; }
    string Name { get; set; }
}

Итак, вот мои вопросы:

• Предполагая, что в модели Order больше свойств, и многие из этих свойств совместно используются DTO «Создать» и «Обновить», имеет ли смысл расширять эти классы от общего базового класса? Если да, должен ли DTO «Получить» (OrderData )также расширяться от этого класса? Если мы это сделаем, не останутся ли эти DTO слишком зависимыми друг от друга?

• Если все свойства являются общими для DTO «Создать» и «Обновить», должны ли мы по-прежнему создавать два разных DTO? Если да, то почему? Если нет, (это просто вопрос об имени )как следует называть DTO «CreateOrUpdate», чтобы имя явно отличалось от DTO «Get»?

• Можно ли добавлять ко всем DTO что-то вроде «Data», «DataObject» или «Dto»?

• Мы на правильном пути здесь? Если нет, то как можно улучшить этот дизайн?

Обновление:

Я думаю, что мне не нравится наследование в DTO, потому что базовый класс также будет представлен в WSDL, и клиент сможет его увидеть и создать его экземпляр, что кажется мне грязным (, см. это:Сериализация WCF с наследованием объектов?). Как насчет использования интерфейсов в DTO для обеспечения соблюдения общих свойств вместо наследования? Поскольку в DTO не должно быть никакого поведения, мы не много теряем, заменяя наследование.