Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
спасибо за статью,
буквально только вчера прочитал статью Дино Эспозито про плюсы и минусы DTO, а тут еще немного материала для размышления
* по моему для лучшего понимания стоило в примере сделать класс Banana более сложным, с большим количеством полей, чтобы показать отличие от DTO-класса
буквально только вчера прочитал статью Дино Эспозито про плюсы и минусы DTO, а тут еще немного материала для размышления
* по моему для лучшего понимания стоило в примере сделать класс Banana более сложным, с большим количеством полей, чтобы показать отличие от DTO-класса
пожалуй так и сделаю
эх DTO весчь
мы сначала кидались DO объектами прямо взятыми из EF контекста через сервер, но потом сделали DTO и все стало гораздо удобнее). и вот AutoMapper то чего так не хватало
мы сначала кидались DO объектами прямо взятыми из EF контекста через сервер, но потом сделали DTO и все стало гораздо удобнее). и вот AutoMapper то чего так не хватало
оверкодинга много? в смысле напряжно ли было вам делать DTO-классы? и делали ли вы их для всех сущностей или выборочно как-то? вообще, может статью напишите со своим опытом? интересно
много,
сами классы не напряжно, а вот то что тут названно мэппингом, а я бы назвал конвертером, было тяжко. do объекты имеют связи замкнутые, колец несколько и они еще и друг с другом связаны — в общем жуть
статью, да имеет смысл — наш пример как раз применение EF в многоуровневом приложении, и чего мы только не словили с ним, и уже 1,5 года и все равно всплавают подробности пейзажа.
вот завтра улетаю в отпуск, постараюсь изложить за месяц
сами классы не напряжно, а вот то что тут названно мэппингом, а я бы назвал конвертером, было тяжко. do объекты имеют связи замкнутые, колец несколько и они еще и друг с другом связаны — в общем жуть
статью, да имеет смысл — наш пример как раз применение EF в многоуровневом приложении, и чего мы только не словили с ним, и уже 1,5 года и все равно всплавают подробности пейзажа.
вот завтра улетаю в отпуск, постараюсь изложить за месяц
Оверкодинга нет, если не делать DO и оставить только дто :) Т.е, не юзать сторонний ОРМ. Возникает задачка написания кода, который будет класть дто в бд и читать в дто из базы, но как показывает практика, все неплохо инкапсулировалось до уровня «это-сюда». Контроля больше, скорости выше:)
Мне тоже приходилось сталкиваться с этой задачей. Мне кажется что пример мог бы быть и посложнее, потому как обычное копирование полей или свойств можно реализовать через
DynamicMethod – заплатить стоимость reflection один раз, а дальше пользоваться. Также для простых примеров наверняка неплохо подойдет Boo.
Я с трубом поняла, о чём речь.
Пришлось дважды прочитать.
Пришлось дважды прочитать.
Нда, сначала создаем себе трудности, а потом героически их преодолеваем.
альтернатива?
Не лезть в DDD.
DDD вообще, неокрепшим девелоперам разрывает мозг напроч — вышеизложенная статья характерный пример.
90% кода занимается тем, что перекладывает из одного в другое и, конечно же мы нарисуем супермаппер, чтобы облегчить эту тяжелую работу.
DDD вообще, неокрепшим девелоперам разрывает мозг напроч — вышеизложенная статья характерный пример.
90% кода занимается тем, что перекладывает из одного в другое и, конечно же мы нарисуем супермаппер, чтобы облегчить эту тяжелую работу.
как бээ что то не делать — это не альтернатива
альтернатива это делай не так а вот так))
альтернатива это делай не так а вот так))
Это альтернатива. Альтернативой созданию себе трудностей собственными руками, является не создавание себе трудностей. Хорошо, переформулирую свою мысль — «делай не DDD».
По признанию самого Фаулера, область применения Rich Dmain Model — очень узка, по моим наблюдениям, ее не видно и в микроскоп, но в последнее время складывается впечатление, что как только девелопер открывает книжку про DDD, мозг у него отключается. Народ начинает писать строго следуя тому, что завещал великий (Фаулер/ Эванс/Нильсен — нужное подчеркнуть), а потом мужественно борется с последствиями и на выходе получаются такие вот фреймворки по снижению негативного влияния других фреймворков.
Поэтому, прежде чем влезать в DDD надо задать себе вопрос «а зачем?», «какую проблему я решаю, применяя здесь DDD, Rich Domain и прочие околоархитектурные изыски?». Такой вопрос в принципе неплохо бы себе по чаще задавать…
Есть еще более правильный путь — понять, что стоит за DDD, и при разработке пользоваться базовыми принципами. И если следуя этоим базовым принципам, таки получилось что-то похожее на DDD, значит в этом проекте действительно должно быть DDD, но вот если DDD не срастается — значит не судьба. В этом случае, необходимость в подобных автомаперах сильно уменьшится, а код будет проще, понятнее и его будет легче сопровождать и расширять, проверено на людях.
По признанию самого Фаулера, область применения Rich Dmain Model — очень узка, по моим наблюдениям, ее не видно и в микроскоп, но в последнее время складывается впечатление, что как только девелопер открывает книжку про DDD, мозг у него отключается. Народ начинает писать строго следуя тому, что завещал великий (Фаулер/ Эванс/Нильсен — нужное подчеркнуть), а потом мужественно борется с последствиями и на выходе получаются такие вот фреймворки по снижению негативного влияния других фреймворков.
Поэтому, прежде чем влезать в DDD надо задать себе вопрос «а зачем?», «какую проблему я решаю, применяя здесь DDD, Rich Domain и прочие околоархитектурные изыски?». Такой вопрос в принципе неплохо бы себе по чаще задавать…
Есть еще более правильный путь — понять, что стоит за DDD, и при разработке пользоваться базовыми принципами. И если следуя этоим базовым принципам, таки получилось что-то похожее на DDD, значит в этом проекте действительно должно быть DDD, но вот если DDD не срастается — значит не судьба. В этом случае, необходимость в подобных автомаперах сильно уменьшится, а код будет проще, понятнее и его будет легче сопровождать и расширять, проверено на людях.
вы правы. два года и фейл после ддд в проекте. сейчас переписываем на обобщенные дто:) идет неплохо. и никаких фреймворков.
А расскажите в чём именно фейл случился? Интересно было бы почитать.
acerv.habrahabr.ru/blog/59210/
ну вот вкратце. правда, придется меня в друзья добавить:)
ну вот вкратце. правда, придется меня в друзья добавить:)
В DDD лазать не надо, факт.
Но паттерны DDD можно успешно применять и в небольших проектах. Например, работать с объектной моделью все-таки проще, чем с Typed DataSet. А передавать в UI эти, условно назовем их, объекты-сущности как-то некайфово. Например, у меня есть класс Product, и у него свойство Category типа ProductCategory. Тогда, например, в какой-нибудь EditModel мне понадобится свойство CategoryId, чтобы воспользоваться дропдауном. А во ViewModel — свойство CategoryName. Навешивать эти свойства на наш класс Product — нарушать SRP. Класс распухнет и станет неуправляемым, даже если у него нет какого-то существенного поведения. А вот dto можно, при желании, сгенерить через T4, отмаппить автомаппером, и никаких дополнительных хлопот у нас не будет.
Короче, если не комплексовать по поводу того, что у меня анемичная доменная модель, то вполне можно разделять entity и DTO, и не жужжать…
Но паттерны DDD можно успешно применять и в небольших проектах. Например, работать с объектной моделью все-таки проще, чем с Typed DataSet. А передавать в UI эти, условно назовем их, объекты-сущности как-то некайфово. Например, у меня есть класс Product, и у него свойство Category типа ProductCategory. Тогда, например, в какой-нибудь EditModel мне понадобится свойство CategoryId, чтобы воспользоваться дропдауном. А во ViewModel — свойство CategoryName. Навешивать эти свойства на наш класс Product — нарушать SRP. Класс распухнет и станет неуправляемым, даже если у него нет какого-то существенного поведения. А вот dto можно, при желании, сгенерить через T4, отмаппить автомаппером, и никаких дополнительных хлопот у нас не будет.
Короче, если не комплексовать по поводу того, что у меня анемичная доменная модель, то вполне можно разделять entity и DTO, и не жужжать…
Начало статьи показалось весьма сложным и чуть было даже не отложить чтиво, но пересилил себя и дочитал. К великому удивлению к концу статьи все оказалось до нельзя очевидным и понятным.
Возможно стоило начать с примера и закончить теорией — для большей доступности материала для тех, кто «не в теме», так сказать.
За статью спасибо, покрайней мере определился что в текущем проекте этот мапер мне на врятли понадобится. Но на будущее — буду иметь ввиду.
Возможно стоило начать с примера и закончить теорией — для большей доступности материала для тех, кто «не в теме», так сказать.
За статью спасибо, покрайней мере определился что в текущем проекте этот мапер мне на врятли понадобится. Но на будущее — буду иметь ввиду.
public bool CocaineInjection { get; set; } а ты шутник :)
А Business Logic Toolkit не пробовали? bltoolkit.net/
RSDN-овский проект ( www.rsdn.ru ), с гораздо более длинной историей чем год развития и обширными возможностями.
С мэпингом объектов там все очень культурно: bltoolkit.net/doc/Mapping/ObjectToObject.htm
Как видно, наглядность на высоте. :)
А если учесть что это и не 1\100 его фич, например оно так же замечательно мэпит базы:
bltoolkit.net/doc/DataAccess/index.htm — так и вообще сказка. :)
RSDN-овский проект ( www.rsdn.ru ), с гораздо более длинной историей чем год развития и обширными возможностями.
С мэпингом объектов там все очень культурно: bltoolkit.net/doc/Mapping/ObjectToObject.htm
Как видно, наглядность на высоте. :)
А если учесть что это и не 1\100 его фич, например оно так же замечательно мэпит базы:
bltoolkit.net/doc/DataAccess/index.htm — так и вообще сказка. :)
Не понимаю в чем преимущество маппера над extension методами а-ля
public static BananaWrapper ToBananWrapper(this Banana entity)
вынесенными в отдельный класс DataExtensions
public static BananaWrapper ToBananWrapper(this Banana entity)
вынесенными в отдельный класс DataExtensions
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вы подготовились к приходу AutoMapper?