Comments 9
Уж очень коротко написано. С таким подходом автоматически лишаемся валидации маппинга, снижаются возможности кастомизации, не совсем понятна ситуация с обработкой ошибок и теперь код который должен маппить заодно лезет в базу и тащит связанные сущности по одной.
TypeConverter by design лишает вас валидации маппинга, хотя можно написать вручную. В данном случае я предполагаю, что Dto может использоваться и для частичного update существующей сущности, соответственно необходимо обновить только часть полей. Ситуация с обработкой ошибок не совсем понятна, потому что зависит от того как вы обрабатываете ошибки в своем приложении: это не тема данного материала. По поводу «лезет в базу и вытаскивает по одной»: вы все-равно будете лезть в базу и вытаскивать по одной для корней агрегации (на то они и корни). Исключением может быть наличие нескольких связей с другой сущностью, но это очень редкий случай.
> вы все-равно будете лезть в базу и вытаскивать по одной для корней агрегации
с чего бы?
с чего бы?
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: принят такой стандарт.
Это никуда не годится! Давайте пойдём дальше и вынесем это поведение в (де)сериалайзер, чтобы вместо бестолковых DTO к нам в action methods сразу приходили готовые сущности (сэкономили кучу времени — DTO писать не нужно). А чтобы совсем симметрично было, давайте сделаем кастомный parameter binding: зачем читать "/{id}" как int/long/string, если в итоге нужна сущность? Давайте сразу в готовые сущность такие параметры резолвить! :-)
Совет Джефри Рихтера: используйте ToUpperInvariant()
Sign up to leave a comment.
Немного о нетрадиционном маппинге