Pull to refresh

Comments 37

спасибо за статью,
буквально только вчера прочитал статью Дино Эспозито про плюсы и минусы DTO, а тут еще немного материала для размышления

* по моему для лучшего понимания стоило в примере сделать класс Banana более сложным, с большим количеством полей, чтобы показать отличие от DTO-класса
пожалуй так и сделаю
эх DTO весчь
мы сначала кидались DO объектами прямо взятыми из EF контекста через сервер, но потом сделали DTO и все стало гораздо удобнее). и вот AutoMapper то чего так не хватало
оверкодинга много? в смысле напряжно ли было вам делать DTO-классы? и делали ли вы их для всех сущностей или выборочно как-то? вообще, может статью напишите со своим опытом? интересно
много,
сами классы не напряжно, а вот то что тут названно мэппингом, а я бы назвал конвертером, было тяжко. do объекты имеют связи замкнутые, колец несколько и они еще и друг с другом связаны — в общем жуть
статью, да имеет смысл — наш пример как раз применение EF в многоуровневом приложении, и чего мы только не словили с ним, и уже 1,5 года и все равно всплавают подробности пейзажа.
вот завтра улетаю в отпуск, постараюсь изложить за месяц
отлично, жду с нетерпением
Оверкодинга нет, если не делать DO и оставить только дто :) Т.е, не юзать сторонний ОРМ. Возникает задачка написания кода, который будет класть дто в бд и читать в дто из базы, но как показывает практика, все неплохо инкапсулировалось до уровня «это-сюда». Контроля больше, скорости выше:)
не использовать ORM — это не айс :-) зачем тогда DTO нужны?
Как интерфейсная часть между слоями:)
гложат меня сомнения о том, что хуже: самописный велосипед для доступа к данным или небольшой оверкодинг? :)
В чем лисапед? Лисапеда нет:)
адо.нет и все такое это не лисапед:)
Мне тоже приходилось сталкиваться с этой задачей. Мне кажется что пример мог бы быть и посложнее, потому как обычное копирование полей или свойств можно реализовать через DynamicMethod – заплатить стоимость reflection один раз, а дальше пользоваться. Также для простых примеров наверняка неплохо подойдет Boo.
писал под level 100, с примером решил не усложнять
Я с трубом поняла, о чём речь.
Пришлось дважды прочитать.
UFO just landed and posted this here
Нда, сначала создаем себе трудности, а потом героически их преодолеваем.
Не лезть в DDD.
DDD вообще, неокрепшим девелоперам разрывает мозг напроч — вышеизложенная статья характерный пример.
90% кода занимается тем, что перекладывает из одного в другое и, конечно же мы нарисуем супермаппер, чтобы облегчить эту тяжелую работу.

как бээ что то не делать — это не альтернатива
альтернатива это делай не так а вот так))
Это альтернатива. Альтернативой созданию себе трудностей собственными руками, является не создавание себе трудностей. Хорошо, переформулирую свою мысль — «делай не DDD».
По признанию самого Фаулера, область применения Rich Dmain Model — очень узка, по моим наблюдениям, ее не видно и в микроскоп, но в последнее время складывается впечатление, что как только девелопер открывает книжку про DDD, мозг у него отключается. Народ начинает писать строго следуя тому, что завещал великий (Фаулер/ Эванс/Нильсен — нужное подчеркнуть), а потом мужественно борется с последствиями и на выходе получаются такие вот фреймворки по снижению негативного влияния других фреймворков.
Поэтому, прежде чем влезать в DDD надо задать себе вопрос «а зачем?», «какую проблему я решаю, применяя здесь DDD, Rich Domain и прочие околоархитектурные изыски?». Такой вопрос в принципе неплохо бы себе по чаще задавать…
Есть еще более правильный путь — понять, что стоит за DDD, и при разработке пользоваться базовыми принципами. И если следуя этоим базовым принципам, таки получилось что-то похожее на DDD, значит в этом проекте действительно должно быть DDD, но вот если DDD не срастается — значит не судьба. В этом случае, необходимость в подобных автомаперах сильно уменьшится, а код будет проще, понятнее и его будет легче сопровождать и расширять, проверено на людях.
вы правы. два года и фейл после ддд в проекте. сейчас переписываем на обобщенные дто:) идет неплохо. и никаких фреймворков.
А расскажите в чём именно фейл случился? Интересно было бы почитать.
что-то я публикацию всё равно не могу прочитать. Доступ закрыт.
В DDD лазать не надо, факт.

Но паттерны DDD можно успешно применять и в небольших проектах. Например, работать с объектной моделью все-таки проще, чем с Typed DataSet. А передавать в UI эти, условно назовем их, объекты-сущности как-то некайфово. Например, у меня есть класс Product, и у него свойство Category типа ProductCategory. Тогда, например, в какой-нибудь EditModel мне понадобится свойство CategoryId, чтобы воспользоваться дропдауном. А во ViewModel — свойство CategoryName. Навешивать эти свойства на наш класс Product — нарушать SRP. Класс распухнет и станет неуправляемым, даже если у него нет какого-то существенного поведения. А вот dto можно, при желании, сгенерить через T4, отмаппить автомаппером, и никаких дополнительных хлопот у нас не будет.

Короче, если не комплексовать по поводу того, что у меня анемичная доменная модель, то вполне можно разделять entity и DTO, и не жужжать…
Начало статьи показалось весьма сложным и чуть было даже не отложить чтиво, но пересилил себя и дочитал. К великому удивлению к концу статьи все оказалось до нельзя очевидным и понятным.

Возможно стоило начать с примера и закончить теорией — для большей доступности материала для тех, кто «не в теме», так сказать.

За статью спасибо, покрайней мере определился что в текущем проекте этот мапер мне на врятли понадобится. Но на будущее — буду иметь ввиду.
public bool CocaineInjection { get; set; } а ты шутник :)
UFO just landed and posted this here
А Business Logic Toolkit не пробовали? bltoolkit.net/

RSDN-овский проект ( www.rsdn.ru ), с гораздо более длинной историей чем год развития и обширными возможностями.
С мэпингом объектов там все очень культурно: bltoolkit.net/doc/Mapping/ObjectToObject.htm

Как видно, наглядность на высоте. :)

А если учесть что это и не 1\100 его фич, например оно так же замечательно мэпит базы:
bltoolkit.net/doc/DataAccess/index.htm — так и вообще сказка. :)
спасибо, дело сделано ;)
UFO just landed and posted this here
Не понимаю в чем преимущество маппера над extension методами а-ля
public static BananaWrapper ToBananWrapper(this Banana entity)
вынесенными в отдельный класс DataExtensions
В том, что не придется писать кучу однотипных присваиваний значений полей между связываемыми типами?
Sign up to leave a comment.

Articles