Немного о нетрадиционном маппинге

[@kemsky]

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

[@marshinov]

TypeConverter by design лишает вас валидации маппинга, хотя можно написать вручную. В данном случае я предполагаю, что Dto может использоваться и для частичного update существующей сущности, соответственно необходимо обновить только часть полей. Ситуация с обработкой ошибок не совсем понятна, потому что зависит от того как вы обрабатываете ошибки в своем приложении: это не тема данного материала. По поводу «лезет в базу и вытаскивает по одной»: вы все-равно будете лезть в базу и вытаскивать по одной для корней агрегации (на то они и корни). Исключением может быть наличие нескольких связей с другой сущностью, но это очень редкий случай.

[@areht]

> вы все-равно будете лезть в базу и вытаскивать по одной для корней агрегации

с чего бы?

[@marshinov]

public class Ar  : Entity
{
     public Foo Foo { get; set; }

     public Bar Bar { get; set; }
}

public class ArDto
{
     public int FooId { get; set; }

     public int BarId { get; set; }
}

Покажите пожалуйста, как вы для сохранения Ar в БД получите инстансы Foo и Bar одним запросом? В первом абзаце я явно указал, что CQRS не используется, писать из Dto сразу в БД нельзя, нужно создавать «правильную» entity и сохранять ее с помощью ORM. У Ar нет FooId и BarId: принят такой стандарт.

[@areht]

Мне показалось речь о том, что при маппинге массива из n «корней агрегации»(мн.ч.) мы получим n*m запросов для одноуровневого агрегата.

[@marshinov]

Это не так.

[@js605451]

Это никуда не годится! Давайте пойдём дальше и вынесем это поведение в (де)сериалайзер, чтобы вместо бестолковых DTO к нам в action methods сразу приходили готовые сущности (сэкономили кучу времени — DTO писать не нужно). А чтобы совсем симметрично было, давайте сделаем кастомный parameter binding: зачем читать "/{id}" как int/long/string, если в итоге нужна сущность? Давайте сразу в готовые сущность такие параметры резолвить! :-)

[@marshinov]

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

[@halex2005]

Совет Джефри Рихтера: используйте ToUpperInvariant()