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

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

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

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

class Order

{

    int CreatedBy { get; set; }

    DateTime CreatedOn { get; set; }

    string Description { get; set; }

    int Id { get; set; }

    string Name { get; set; }

}

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

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

class CreateOrderData

{

    int CreatedBy { get; set; }

    string Description { get; set; }

    string Name { get; set; }

}

метод Update : пользователь не может указать идентификатор ., CreatedOn и CreatedBy свойства, поэтому DTO выглядит следующим образом:

class UpdateOrderData

{

    string Description { get; set; }

    string Name { get; set; }

}

Get метод: пользователь должен иметь возможность видеть все для заказа, поэтому DTO выглядит следующим образом это:

class OrderData

{

    int CreatedBy { get; set; }

    DateTime CreatedOn { get; set; }

    string Description { get; set; }

    int Id { get; set; }

    string Name { get; set; }

}

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

• 
  

  Если предположить, что в модели порядка существует больше свойств и многие из этих свойств совместно используются между DTO" Create "и" Update", имеет ли смысл расширять эти классы из общего базового класса? Если да, то должен ли" Get " DTO (OrderData) также распространяться из этого класса? Если мы сделаем это, не оставит ли это этих DTO слишком зависимыми друг от друга?



• 
  

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



• 
  

  Это нормально суффикс все объекты переноса данных с что-то вроде "данные" или "объект dataObject" или "ДТО"?



• 
  

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

Обновление:

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