Comments 5
К сожалению, автор не владеет ORM, но критикует их. Здесь он допустил две грубейших ошибки и продолжает «мы должны разработать слой трансляции, который смог бы транслировать DTO-объекты в правильно инкапсулированные доменные объекты» не понимая, что так он лишается функционала lazy-загрузки и оптимальных трансляций ORM-запросов в SQL-запросы. Автор даже не пытается заполнить появившиеся дыры, он просто не знает об этих проблемах, которые неизбежны в больших приложениях и привели нас пусть к ООП-кривым, но эффективным ORM.
Плюс в ORM без годогеренации вполне можно соблюсти контракты, добавляя конструктор по умолчанию с модификатором доступа private, чтобы к нему имела доступ только ORM
Ну не знаю, мне показалось, что автор всего лишь решил побыть К.О. и написал банальное: value objects — это не ООП.
Да что же вы только про ORM и говорите? И откуда в слое трансляции DTO в доменные объекты вообще будут lazy-загрузки и SQL-запросы?
Автор же общие случаи рассматривает, не сужая их до частностей типа ORM/EF. А вы всю его мысль рубите, потому что на стыке приложения и реляционной БД мы получаем спорное и усложняющее жизнь утверждение.
Автор же общие случаи рассматривает, не сужая их до частностей типа ORM/EF. А вы всю его мысль рубите, потому что на стыке приложения и реляционной БД мы получаем спорное и усложняющее жизнь утверждение.
спасибо за перевод увлекательной серии. пусть изложенная автором в цикле статей точка зрения не претендует на абсолютную истину и в чем-то спорна, в ней определенно есть ряд рациональных моментов.
кажется, пример в последнем абзаце сбивает с толку. я всегда считал Entiy вполне нормальными объектами, т.к. они, по определению, обладают собственным абстрактным поведением. скорее, ближайшим родственником DTO является «сообщение», как пример структурированных данных, не обремененных собственной прикладной семантикой, которые летают между границами систем.
DTO это взгляд на сообщение со стороны кода. они абстрагируют приложение от конкретного формата сообщений (sql, xml, json,… ), предоставляя доступ к внутренностям в виде родных синтаксических конструкций языка (в случае с EF это еще и аннотации для автоматической сериализации/десериализации, схемогенерации, миграций и т.п. полезных наворотов, реализуемых фреймворком, но роли самих DTO это не меняет). в плане структурно-поведенческого дуализма объектов, DTO представляю собой вырожденный случай структурности в чистом виде.
кажется, пример в последнем абзаце сбивает с толку. я всегда считал Entiy вполне нормальными объектами, т.к. они, по определению, обладают собственным абстрактным поведением. скорее, ближайшим родственником DTO является «сообщение», как пример структурированных данных, не обремененных собственной прикладной семантикой, которые летают между границами систем.
DTO это взгляд на сообщение со стороны кода. они абстрагируют приложение от конкретного формата сообщений (sql, xml, json,… ), предоставляя доступ к внутренностям в виде родных синтаксических конструкций языка (в случае с EF это еще и аннотации для автоматической сериализации/десериализации, схемогенерации, миграций и т.п. полезных наворотов, реализуемых фреймворком, но роли самих DTO это не меняет). в плане структурно-поведенческого дуализма объектов, DTO представляю собой вырожденный случай структурности в чистом виде.
Sign up to leave a comment.
На границах, приложения не являются объектно-ориентированными