Мы используем 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; }
}
Метод 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-типами "Создать" и "Обновить", имеет ли смысл, чтобы эти классы распространялись от общего базового класса? Если да, должен ли "Получить" DTO (OrderData) также распространяться из этого класса? Если мы это сделаем, не оставит ли эти DTO слишком зависимыми друг от друга?
-
Если все свойства являются общими между "Create" и "Update" DTO, мы должны создать два разных DTO? Если да, то почему? Если нет, (теперь это только вопрос об именах), что должно вызывать DTO "CreateOrUpdate", чтобы имя, очевидно, отличалось от "Get" DTO?
-
Можно ли суффиктировать все DTO с чем-то вроде "Data" или "DataObject" или "Dto"?
-
Мы на правильном пути? Если нет, как можно улучшить дизайн?
Update:
Я думаю, что мне не нравится наследование в DTO, потому что базовый класс также будет отображаться в WSDL, и клиент сможет увидеть его и создать экземпляр, который кажется мне грязным (см. это: Сериализация WCF с наследованием объектов?). Как насчет использования интерфейсов в DTO для принудительного применения общих свойств вместо наследования? Поскольку DTO не должны иметь никакого поведения в них, мы не теряем много, заменив наследование.