Model (M-VC) != Domain Model

472 views
Skip to first unread message

Alexander Byndyu

unread,
May 1, 2012, 3:48:56 PM5/1/12
to dotne...@googlegroups.com
Всем привет!

Спорный пост http://www.calabonga.net/blog/post/77

Хотел написать по этому поводу статью, но видимо время в ближайшем будущем не будет. Предлагаю обсудить здесь.

Как я бы хотел изменить решение, которое предложено в статье и почему?

MVC
Для начала надо понять, что такое MVC и зачем оно надо. Запрос, который приходит извне сначала попадает в контроллер -  C. Контроллер, руководствуясь своей логикой собирает модель для отображения данных в ответ на запрос - M. Собранную модель контроллер передает в одно из подготовленных отображений View.

В данном случае модель необходима как объект, который содержит в себе необходимый набор данных. Например, на форме надо показать пользователей и напротив каждого поставить галочку с выбором роли этого пользователя - настройка прав доступа в системе. Возможность поставить галочку в ту или иную роль будет зависеть от того есть у пользователя купленные продукты или нет. Что в этом случае представляет собой модель данных? Это будет объект, который содержит некоторые данные пользователей, некоторые данные ролей и некоторые данные о продуктах. Это может быть имя пользователя, причем для этого отображения имя берется, как логин + ID, кол-во продуктов, купленных пользователем в определенный период и т.д.

Этот набор данных формируется, исходя из требований к модели для отображения данных. Например, в передаваемой модели может быть поле IsEnabledForCheck, которое в домене ничего не значит.

Domain
Что такое домен приложения? Приведу пару определений http://martinfowler.com/eaaCatalog/domainModel.html и http://en.wikipedia.org/wiki/Domain_model. Сфера использования домена приложения - любая подсистема нашего проекта, включая отображение данных через MVC (возможны веб-сервис, win-сервисы, WinForms и т.п.)

Итого
Если подвести итог, то модель в MVC и доменная модель "играют за разные команды".  

Передавать объекты, которые описывают ваш домен напрямую в отображение можно только в очень простых CRUD приложения, которые никогда никто не будет развивать (да, я допускаю, что в очень простых случаях это возможно, но с большими оговорками). Иначе правила из отображения полезут в домен, либо при усложнении отображения данных вам придется переписывать значительные части системы.

ORM
Дополнительную тему можно раскрыть про передачу объектов, полученных из ORM. Если в таких объектах включен LazyLoad, то прямо во View я встречаю код:

@post.Comments.Where(x => x.IsDeleted == false)

Ничего не мешает написать такой код, который во View подгрузит комментарии и выберет из них те, что не удалены. Теперь наше бизнес-правило начинает жить в отображении данных, думаю, что не надо останавливаться на том, почему это плохо и чем грозит.

Даже если  LazyLoad не включен, то подобный код можно написать, размазав тем самым бизнес-логику по всему приложению.

"О, это чудо! Контейнер, репозитории, EF и всё работает!" (с) из статьи
Да, это чудо и правда работает. Microsoft воспитывает в разработчиках именно такой подход. Для тех, у кого быстро и просто сначала, к сожалению, долго и трудно потом. Мы не кидаем Drag&Drop'ом компонент Connection на WinForms, для этого есть определенные причины. От приложения к приложению надо искать именно смысл концепций. Почему MVC? Что такое MVC? Как сделать этот шаблон лучше? Почему не использовать другой? В чем суть Model? В чем суть View? В чем суть Controller? Только эти вопросы сделают нас сильнее.

Всё написанное выше следует из моего опыта разработки. Буду рад услышать ваше мнение по этому вопросу.

--
Best regards,
Byndyu Alexander

Phone: +7 (904) 305 5263
Skype: alexander.byndyu
Blog: http://blog.byndyu.ru
Twitter: alexanderbyndyu

ShuriK

unread,
May 1, 2012, 7:08:54 PM5/1/12
to dotne...@googlegroups.com
Если подвести итог, то модель в MVC и доменная модель "играют за разные команды".  
Много раз ловил себя на искушении использовать имеющийся объект доменной модели для View, вроде бы все красиво и ничего больше не понадобится... Но через пару релизов кто-то добрый просит "подсветить" колонку или добавить еще одну с накапливаемым итогом и.т.д. В результате таки рождается объект непосредственно под View cо всеми последствиями, в противном случае доменный объект рискует превратиться в нечто монтстрообразное. 
Имхо на каждую V должна быть своя М, путь это будет просто обертка над доменным объектом с одним лишним полем или даже без него, хоть на это и уйдет немного времени на старте, но зато потом гораздо проще рефакторить и сопровождать.

Если в таких объектах включен LazyLoad, то прямо во View я встречаю код: 
Имхо для этих целей есть репозитории и подобные фильтры допускаются только если это "пользовательская" фильтрация, когда лучше больше перетянуть на клиента, на случай если понадобится.
В этом плане очень хорошо ложатся идеи CQRS, когда под каждое View имеется чуть ли не своя таблица в БД и соответствующее DTO и подобная фильтрация может встретится на клиенте только там где это действительно  необходимо, ибо если это не требуется клиенту, то в таблице данных с IsDeleted == true просто не будет.


О, это чудо! Контейнер, репозитории, EF и всё работает! 
Чудес не бывает, а если вы видите чудо то ищите баги и ждите проблем, даже если их нет сейчас то они появятся очень скоро ;)

Артур Терегулов

unread,
May 1, 2012, 7:38:39 PM5/1/12
to dotne...@googlegroups.com
а кто заставляет модели играть за разные команды? у меня контроллеры работают ViewModel и DataModel, а с моделью домена работает бизнес-логика, поэтому, модель домена совпадает с моделью в MVC в той части где это не обременительно

Artur Drobinskiy

unread,
May 1, 2012, 11:38:42 PM5/1/12
to dotne...@googlegroups.com
О каждой задаче надо говорить в своём контексте.
По мне так на примере такой простейшей задачи и репозитории более чем избыточны, но это вполне можно оправдать знакомством читателя с MvcScaffolding.

А вот Саша Зайцев умудрился на этом примере еще и охаять выбор Unity и EntityFramework. Да, я бы тоже выбрал другие orm и ioc, но Unity и EF не настолько плохи, чтобы можно было говорить "никогда их не используйте". 
Аргументация "в больших приложениях у вас будут проблемы" при обсуждении простых примеров, которые показывают базовые возможности фреймворков, имхо, вообще моветон. Так можно и разругаться, почему же в этом простом примере автор не использует ТДД (без него будут проблемы!), да и вообще о тестах не заикается (а я как раз видел статьи, где описывали nHibernate с тестами - это только отвлекает).

Ну и отдельно хотелось бы возразить по поводу:
Передавать объекты, которые описывают ваш домен напрямую в отображение можно только в очень простых CRUD приложения, которые никогда никто не будет развивать
и согласиться с:
модель домена совпадает с моделью в MVC в той части где это не обременительно 
:)
В моей практике скорее наоборот, в сложных ситуациях модель не является просто композицией доменных объектов. В большинстве случаев это ни к каким проблемам не приводит. Более того, это приводит к отсутствию доп. слоев и очень удобному байндингу :)
Но, конечно, при добавлении полей стоит думать головой, добавлять ли поле в домен. Но думать вообще всегда полезно :)


Артур


2 мая 2012 г. 2:48 пользователь Alexander Byndyu <alexande...@gmail.com> написал:

Alexander I. Zaytsev

unread,
May 2, 2012, 3:02:36 AM5/2/12
to dotne...@googlegroups.com
Привет!

>А вот Саша Зайцев умудрился на этом примере еще и охаять выбор Unity и EntityFramework.

У меня достаточно опыта с этими реализациями, чтобы так заявлять. Мое наблюдение - технологии, рожденные из NIH-syndrome убоги и неудобны. Но, т.к. это M$, то очень хорошо продается потому, что "это от M$". Так же, M$ очень часто насаждает технологию, чтобы разработчиков подсадить на крючок. К примеру, один из таких крючков: они добавили EF в шаблоны проекта для MVC 3.1.

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

Мне напомнило вот это:
xxx:
Сначала, в начальной школе, нам говорят, что нельзя вычитать из большего меньшее. Потом, в старших классах, оказывается, что всё-таки можно. Тогда говорят, что нельзя делить на ноль. Потом, в высшей школе, оказывается, что иногда всё-таки можно.

Что дальше, господа? Помру — а там бородатый мужик скажет: «Да ладно, чувак, смотри: вот тебе и скорости больше скорости света, вот тебе и тахион — о, смотри, полетел. Подбери челюсть, пошли лучше на суперструнах поиграем»?

Дак вот по этой причине, я считаю, что даже в простых примерах, нужно показывать как делать ПРАВИЛЬНО, а не абы как. Либо, КРУПНО НАПИСАТЬ: ЭТО УЧЕБНЫЙ ПРИМЕР, НЕ ДЕЛАЙТЕ ТАК В РЕАЛЬНЫХ ПРОЕКТАХ.


Artur Drobinskiy

unread,
May 2, 2012, 3:59:24 AM5/2/12
to dotne...@googlegroups.com
У меня достаточно опыта с этими реализациями, чтобы так заявлять.
Я думаю, существует множество людей, которые заявят, что у них достаточно опыта с этими реализациями, чтобы заявлять, что с ними всё нормально.
Я одно время работал с Юнити еще даже версии 1.2 - всё было замечательно. ЕФ в отдельных задачах круче/проще/быстрее НХ.

Подход с Query-Command, например, тоже далеко не всегда оптимален. Даже если оптимален - чтобы его изучить и понять, как применять оптимально - нужно время (и много), да и способности. А если применять не разобравшись - будет только лишняя абстракция и нагромождение.
Так вот во всех учебных примерах упоминаются репозитории - поэтому все так и делают. А они тоже не всегда оптимальны. А кучи разработчиков и не задумываются - берут широко упоминаемый шаблон и вперед.

xxx:
Сначала, в начальной школе, нам говорят, что нельзя вычитать из большего меньшее. Потом, в старших классах, оказывается, что всё-таки можно.
Смешной пример, но разве было бы лучше, если бы в начальной школе сразу давали комплексные числа?
Мне как раз кажется логичным, что знакомиться с библиотеками/фреймворками лучше на статьях "начального уровня", не углубляясь в детали, а по мере роста потребностей продолжать изучение принципов и расширений уже по статьям другого уровня, подключая и переосмысляя свой предыдущий опыт проектирования, пусть даже в других областях.


2 мая 2012 г. 14:02 пользователь Alexander I. Zaytsev <hazzik...@gmail.com> написал:

Alexander I. Zaytsev

unread,
May 2, 2012, 4:27:27 AM5/2/12
to dotne...@googlegroups.com


2 мая 2012 г. 13:59 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:

У меня достаточно опыта с этими реализациями, чтобы так заявлять.
Я думаю, существует множество людей, которые заявят, что у них достаточно опыта с этими реализациями, чтобы заявлять, что с ними всё нормально.
Да, они просто не знают того, чего они не знают. Говоря умными словами находятся в квадрате неосознанной некомпетентности ( почитать: http://www.happy-pm.com/blog/?p=3312 ), другими словами - им не с чем сравнивать. Т.е. если ты не знаешь, что бывает что-то лучше, чем то, чем ты пользуешься, то тебя всё устраивает.

У меня есть опыт работы как с EF, так и с другими ORM. Как с Unity, так и с другими IoC => я могу сравнивать и делать выводы. 
 
Я одно время работал с Юнити еще даже версии 1.2 - всё было замечательно. ЕФ в отдельных задачах круче/проще/быстрее НХ.
Не верю, что EF будет работать быстрее NH. Не будьте голословными - приведите пример.

Рассмотрим типичный пример - нужно в базе сохранить поле типа Enum. Оп, а EF этого не умеет. Ок, создаем целочисленное поле и делаем дублирование поля с именем MyFieldEnum. Ок, теперь хотим сделать запрос по этому полю... Хм, дайте подумать... А, да, точно нужно делать запрос по полю с целочисленным значением. Грустно. Я этот пример могу продолжать бесконечно развивая. И это только потому, что EF не поддерживает одну из примитивнейших фич. 
 
Подход с Query-Command, например, тоже далеко не всегда оптимален. Даже если оптимален - чтобы его изучить и понять, как применять оптимально - нужно время (и много), да и способности. А если применять не разобравшись - будет только лишняя абстракция и нагромождение.
Так вот во всех учебных примерах упоминаются репозитории - поэтому все так и делают. А они тоже не всегда оптимальны. А кучи разработчиков и не задумываются - берут широко упоминаемый шаблон и вперед.

xxx:
Сначала, в начальной школе, нам говорят, что нельзя вычитать из большего меньшее. Потом, в старших классах, оказывается, что всё-таки можно.
Смешной пример, но разве было бы лучше, если бы в начальной школе сразу давали комплексные числа?
Мне как раз кажется логичным, что знакомиться с библиотеками/фреймворками лучше на статьях "начального уровня", не углубляясь в детали, а по мере роста потребностей продолжать изучение принципов и расширений уже по статьям другого уровня, подключая и переосмысляя свой предыдущий опыт проектирования, пусть даже в других областях.
Людей умеющих так делать - единицы.

Alexander Milikovski

unread,
May 2, 2012, 4:44:28 AM5/2/12
to dotne...@googlegroups.com
Хочу не согласиться.

на статьях "начального уровня", не углубляясь в детали, а по мере роста потребностей продолжать изучение принципов и расширений уже по статьям другого уровня

Проблема в том, что такие статьи обычно сугубо теоретические. Допустим Мартин Фауллер. Отличный, просто отличный источник знаний у глубоко понимания подходов, паттернов. и что/ Думаете большниство прочитав его стали писать невероятно правильно? Да вообще нет. Говоря на чистоту, большому кол-ву людей требуется пример дабы закрепить теорию и кстати я считаю это нормальным. Если я как таблицу умножения знаю уравнения Максвела это не значит, что я в состоянии собрать рабочую, электронную схему. Значит нужен вместе с теорией и пример, а иначе, читая скажем хотя бы упомянутого Фауллера, в лучшем случаи люди реализует это через жопу, в худшем вообще не поймут как перевести теорию в код. И вот тут в полный рост встаёт проблема адекватных примеров. Если начитавшись и насмотревшись на примеры где не заостряли внимание на деталях, ведь это маленький пример а не полновесный проект, то даже попытабшись понять более глубинные вещи, люди будут продолжать колбасить говнокод. Что они действительно выучат, так это кучу buzzwords.

Людей умеющих так делать - единицы. 

Полностью согласен. 

Artur Drobinskiy

unread,
May 2, 2012, 5:15:42 AM5/2/12
to dotne...@googlegroups.com
Я одно время работал с Юнити еще даже версии 1.2 - всё было замечательно. ЕФ в отдельных задачах круче/проще/быстрее НХ.
Не верю, что EF будет работать быстрее NH. Не будьте голословными - приведите пример.
Не ЕФ будет работать быстрее, а с ЕФ будет работать быстрее.
Пример - конвертация БД из одного формата в другой. Воспользоваться автосгенеренной моделькой от ЕФа быстрее, чем писать все доменные классы руками.


Да, они просто не знают того, чего они не знают. Говоря умными словами находятся в квадрате неосознанной некомпетентности ( почитать: http://www.happy-pm.com/blog/?p=3312 ), другими словами - им не с чем сравнивать. Т.е. если ты не знаешь, что бывает что-то лучше, чем то, чем ты пользуешься, то тебя всё устраивает.
Щас уйдем в глубокое теоретизирование :)
Для выбора используемых технологий есть куча причин - в том числе и уже существующие знания команды по какой-либо технологии, и время "старта", и гарантия поддержки, и уже используемые технологии в проекте (если проект не новый), и сообщество. Грубо говоря, найти специалиста, который знает Юнити или ЕФ проще, чем, допустим, Castle.Windsor и LLBLGen. Пусть и по nih-причинам. На крупных проектах с этим тоже приходится считаться.

А ты говоришь, что выбор ЕФ или Юнити - это исключительно неосознанная некомпетентность. С этим я в корне не согласен.

Человек в статье описал опыт быстрого старта. Он реально быстрый. И простой. Ну да, он с ЕФ. Видимо, с ЕФ старт быстрее.
Говорить, условно, что "ну ты дурак, что же ты не копнул глубже и не написал про НХ и ninject" - ну так он никому не обязан ни о чем писать. Он нашел простое решение. Почему-то решение на НХ для него не показалось проще - как минимум информация о нем нашлась не первой строкой. А это тоже важно.


И вот тут в полный рост встаёт проблема адекватных примеров.
Напишите аналогичное основанное на своих библиотеках - будет отлично (если никто не придет и не скажет, ай-ай-ай, а почему ты не использовал Т4, с ним же в 100 раз быстрее :)).
Больше статей хороших и разных :)
А коменты все равно никто не читает - ругаться там смысла нет :)



2 мая 2012 г. 15:27 пользователь Alexander I. Zaytsev <hazzik...@gmail.com> написал:

Alexander Byndyu

unread,
May 2, 2012, 5:31:10 AM5/2/12
to dotne...@googlegroups.com
Артур,

А вы на View передаете доменные объекты? Интересно ваше мнение по этому вопросу.


--
Best regards,
Byndyu Alexander

Phone: +7 (904) 305 5263
Skype: alexander.byndyu
Blog: http://blog.byndyu.ru
Twitter: alexanderbyndyu



2 мая 2012 г. 15:15 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:

Alexander I. Zaytsev

unread,
May 2, 2012, 5:53:24 AM5/2/12
to dotne...@googlegroups.com


2 мая 2012 г. 15:15 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:

Я одно время работал с Юнити еще даже версии 1.2 - всё было замечательно. ЕФ в отдельных задачах круче/проще/быстрее НХ.
Не верю, что EF будет работать быстрее NH. Не будьте голословными - приведите пример.
Не ЕФ будет работать быстрее, а с ЕФ будет работать быстрее.
Полностью не согласен. Да, возможен(!!!) быстрый старт, но потом обязательно начинаются проблемы. Кроме проблемы enum есть другая проблема - ограниченная поддержка linq. И если в NH есть другие механизмы запросов, то в EF - нет.
 
Пример - конвертация БД из одного формата в другой. Воспользоваться автосгенеренной моделькой от ЕФа быстрее, чем писать все доменные классы руками.
Тут я вообще не буду использовать ORM, и либо напишу запрос, либо буду использовать ADO.NET.

 
Да, они просто не знают того, чего они не знают. Говоря умными словами находятся в квадрате неосознанной некомпетентности ( почитать: http://www.happy-pm.com/blog/?p=3312 ), другими словами - им не с чем сравнивать. Т.е. если ты не знаешь, что бывает что-то лучше, чем то, чем ты пользуешься, то тебя всё устраивает.
Щас уйдем в глубокое теоретизирование :)
Да без проблем - формат группы это позволяет.
 
Для выбора используемых технологий есть куча причин - в том числе и уже существующие знания команды по какой-либо технологии,
Ок, с этим соглашусь.
 
и время "старта",
Не соглашусь, т.к. для NH есть куча автогенераторов, и, по-крайней мере у меня, есть проект для быстрого старта, который позволяет добавлять сущности как обычные классы - добавил реализацию IEntity и оно у тебя уже в базе сохраняется.
 
и гарантия поддержки,
Все ответы оф. тех. поддержки EF были в духе - "Прости, чувак, но EF это не умеет. Не используй это. Но, возможно, будет поддержка в версии vNextNextNext - подожди годик - два". С NH я могу запилить поддержку того, что мне не хватает сам, и, на крайний случай (если мой реквест не приняли), использовать кастомную сборку.

А опыт использования коммерческой LLBLGen вообще был шикарен, любой запрос решался через несколько дней со словами, вот, попробуйте новую сборку - всё уже пофиксено.
 
и уже используемые технологии в проекте (если проект не новый),
Ок, но иногда думать нужно на перед, смотреть какие предложения есть на рынке, сравнивать по различным параметрам и т.д.
 
и сообщество.
Сообщество NH гораздо больше.
 
Грубо говоря, найти специалиста, который знает Юнити или ЕФ проще,
Спорно.
 
чем, допустим, Castle.Windsor и LLBLGen.
Тоже спорно.
 
Пусть и по nih-причинам.
Не понимать.
 
На крупных проектах с этим тоже приходится считаться.
С чем с этим? С мнениями типа "я тут уже 13 лет разрабатываю на EF (подставить любую другую технологию), иди пасись"?
 
А ты говоришь, что выбор ЕФ или Юнити - это исключительно неосознанная некомпетентность.
Я этого не говорил. Я говорил, что те, кто выбирают EF или Unity и другие велосипеды от M$ чаще всего становятся жертвами маркетологов и прочих евангелистов (привет, Сергей) и просто не знают, что есть что-то другое. Т.к. человек, почувствовавший раз силу NH никогда больше не будет использовать EF, а если будет использовать, то будет материться через слово (привет, Тимур;)).
 
С этим я в корне не согласен.
Очень удобно не соглашаться с тем, чего не говорили;) 
 
Человек в статье описал опыт быстрого старта. Он реально быстрый. И простой. Ну да, он с ЕФ. Видимо, с ЕФ старт быстрее.
Ключевое слово "видимо", т.е. из этого предложения я могу сделать вывод, что с NH или LLBLGen вы просто не работали. Старт с NH (используя FNH) быстрее в разы. А с LLBLGen Pro еще быстрее, даже с 0 бэкграундом.
  
Говорить, условно, что "ну ты дурак, что же ты не копнул глубже и не написал про НХ и ninject" - ну так он никому не обязан ни о чем писать.
Ну я этого не говорил. Я просто подтолкнул его своим мнением из неосознанной некомпетентности, теперь, благодаря этому он знает, что кроме EF и Unity есть и другие вещи.
 
Он нашел простое решение. Почему-то решение на НХ для него не показалось проще - как минимум информация о нем нашлась не первой строкой. А это тоже важно.
Откуда вы это знаете? 

И вот тут в полный рост встаёт проблема адекватных примеров.
Напишите аналогичное основанное на своих библиотеках - будет отлично (если никто не придет и не скажет, ай-ай-ай, а почему ты не использовал Т4, с ним же в 100 раз быстрее :)).
Написал. Даже доклад сделал. Вот хочу в одну из библиотек, для быстрого старта впилит поддержку EF, только она че-то как-то не впиливается.
 
Больше статей хороших и разных :)
Лучше меньше, да лучше. Статьи "о, смотрите я смог запустить проект на EF" не нужны, т.к. их уже как биомассы за баней.
 
А коменты все равно никто не читает - ругаться там смысла нет :)
Я сначала комментарии читаю.  

Artur Drobinskiy

unread,
May 2, 2012, 6:01:46 AM5/2/12
to dotne...@googlegroups.com
Передаю доменные объекты, да.

У каждой вьюшки своя ВьюМодель, которая, обычно, содержит несколько доменных объектов. Грубый пример:
public class IndexViewModel {
    public Project Project {get;set;}
    public List<Users> AllUsers {get;set;} 
}
Впечатления в общем весьма положительные. Основной плюс - простота :)

Ну и благодаря кастомному байндеру очень удобно выглядят экшены:

public ActionResult ProjectDetails(Project project) {
}

Получается довольно наглядно.

В сложных случаях, конечно, вьюмоделька растет за счет результатов вычислений/операций внутри контроллера.
Неудобств не заметно.
Как-то так :)


Артур

2 мая 2012 г. 16:31 пользователь Alexander Byndyu <alexande...@gmail.com> написал:

Artur Drobinskiy

unread,
May 2, 2012, 6:32:57 AM5/2/12
to dotne...@googlegroups.com

Не верю, что EF будет работать быстрее NH. Не будьте голословными - приведите пример.
Не ЕФ будет работать быстрее, а с ЕФ будет работать быстрее.
Полностью не согласен. Да, возможен(!!!) быстрый старт, но потом обязательно начинаются проблемы. Кроме проблемы enum есть другая проблема - ограниченная поддержка linq. И если в NH есть другие механизмы запросов, то в EF - нет.
вот уж linq в паре EF-SQLServer просто отлично поддерживается, как на мой взгляд ) Весьма сложные и вложенные вещи отрабатывают вполне на уровне.
 

 
Пример - конвертация БД из одного формата в другой. Воспользоваться автосгенеренной моделькой от ЕФа быстрее, чем писать все доменные классы руками.
Тут я вообще не буду использовать ORM, и либо напишу запрос, либо буду использовать ADO.NET.

 
Да, они просто не знают того, чего они не знают. Говоря умными словами находятся в квадрате неосознанной некомпетентности ( почитать: http://www.happy-pm.com/blog/?p=3312 ), другими словами - им не с чем сравнивать. Т.е. если ты не знаешь, что бывает что-то лучше, чем то, чем ты пользуешься, то тебя всё устраивает.
Щас уйдем в глубокое теоретизирование :)
Да без проблем - формат группы это позволяет.
 
Для выбора используемых технологий есть куча причин - в том числе и уже существующие знания команды по какой-либо технологии,
Ок, с этим соглашусь.
 
и время "старта",
Не соглашусь, т.к. для NH есть куча автогенераторов, и, по-крайней мере у меня, есть проект для быстрого старта, который позволяет добавлять сущности как обычные классы - добавил реализацию IEntity и оно у тебя уже в базе сохраняется.
 
и гарантия поддержки,
Все ответы оф. тех. поддержки EF были в духе - "Прости, чувак, но EF это не умеет. Не используй это. Но, возможно, будет поддержка в версии vNextNextNext - подожди годик - два". С NH я могу запилить поддержку того, что мне не хватает сам, и, на крайний случай (если мой реквест не приняли), использовать кастомную сборку.

А опыт использования коммерческой LLBLGen вообще был шикарен, любой запрос решался через несколько дней со словами, вот, попробуйте новую сборку - всё уже пофиксено.
 
и уже используемые технологии в проекте (если проект не новый),
Ок, но иногда думать нужно на перед, смотреть какие предложения есть на рынке, сравнивать по различным параметрам и т.д.
 
и сообщество.
Сообщество NH гораздо больше.
 
Грубо говоря, найти специалиста, который знает Юнити или ЕФ проще,
Спорно.
 
чем, допустим, Castle.Windsor и LLBLGen.
Тоже спорно.
 
Пусть и по nih-причинам.
Не понимать.
 
Человек в статье описал опыт быстрого старта. Он реально быстрый. И простой. Ну да, он с ЕФ. Видимо, с ЕФ старт быстрее.
Ключевое слово "видимо", т.е. из этого предложения я могу сделать вывод, что с NH или LLBLGen вы просто не работали. Старт с NH (используя FNH) быстрее в разы. А с LLBLGen Pro еще быстрее, даже с 0 бэкграундом.
Я вроде не раз говорил, что сам-то я как раз чаще выбираю НХ+ФНХ+Авто-маппинги, но при уже имеющейся БД и таком объеме статей в сети, я таки не могу согласиться, что с ЕФ старт медленнее. Как минимум потому, что ФНХ не идет "из коробки" с НХ, и к использованию Авто-маппингов тоже еще надо прийти.


 
На крупных проектах с этим тоже приходится считаться.
С чем с этим? С мнениями типа "я тут уже 13 лет разрабатываю на EF (подставить любую другую технологию), иди пасись"?
Ну если ты считаешь нормальной ситуацию в которой, допустим, двухлетний проект на ЕФ, не имеющий никаких существенных проблем вдруг стали переводить на НХ после того как пришел такой молодец со стороны и сказал, "да вы что, ЕФ это прошлый век, енамы не работают", то о business-value у нас совсем разные понятия.
Или ты скажешь, что не существует двухлетних проектов на ЕФ, в которых нет проблем? :)
 
А ты говоришь, что выбор ЕФ или Юнити - это исключительно неосознанная некомпетентность.
Я этого не говорил. Я говорил, что те, кто выбирают EF или Unity и другие велосипеды от M$ чаще всего становятся жертвами маркетологов и прочих евангелистов (привет, Сергей) и просто не знают, что есть что-то другое. Т.к. человек, почувствовавший раз силу NH никогда больше не будет использовать EF, а если будет использовать, то будет материться через слово (привет, Тимур;)).
Я использую ЕФ и не матерюсь. При этом я активно использую НХ, и считаю, что чаще он подходит лучше, чем ЕФ.

Я говорил, что те, кто выбирают EF или Unity и другие велосипеды от M$ чаще всего становятся жертвами маркетологов и прочих евангелистов
Я бы перефразировал, жертвами большого количества информации в сети об этих технологиях. Чем не критерий выбора? 
 
 
С этим я в корне не согласен.
Очень удобно не соглашаться с тем, чего не говорили;) 
 
 
Хм. Это не твои слова?  

Artur Drobinskiy

unread,
May 2, 2012, 6:42:58 AM5/2/12
to dotne...@googlegroups.com
Старт с NH (используя FNH) быстрее в разы.
Под "стартом", чтобы не быть неправильно понятым, я понимаю именно порог вхождения. Первый проект, знакомство с технологией.
"Старт" можно еще трактовать как запуск проекта "с нуля", но я не это имел ввиду в вопросах и ответах.

Eskat0n

unread,
May 2, 2012, 8:18:40 AM5/2/12
to dotne...@googlegroups.com
Порог вхождения в NH, кстати, тоже весьма низкий. У меня до работы с NH был опыт, по сути, только с Ruby и ORM Datamapper. При этом NH в своих основах, лег в голову весьма быстро и удобно. Я не имею в виду, какие-то либо хаки или in-deep понимание, но уровень знания NH на достаточном для написания кода, использующего эту ORM пришел достаточно быстро. Потому как, NH просто берет и работает, так как ты хочешь, так, как по логике должна работать ORM. При базовой (да, в целом, и не только) работе с NH не надо вспоминать множество искусственных ограничений, которые присущи, например, EF.
Так что даже в вашем понимании «старта» он будет более быстрым именно с NH.

2 мая 2012 г. 16:42 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:

Старт с NH (используя FNH) быстрее в разы.
Под "стартом", чтобы не быть неправильно понятым, я понимаю именно порог вхождения. Первый проект, знакомство с технологией.
"Старт" можно еще трактовать как запуск проекта "с нуля", но я не это имел ввиду в вопросах и ответах.



--
Eskat0n, software developer at DoneRight LLC
You can find my contacts and portfolio at following site – http://muyou.koumakan.jp/

Artur Drobinskiy

unread,
May 2, 2012, 10:17:13 AM5/2/12
to dotne...@googlegroups.com
Я, честно говоря, не представляю, какой старт может быть быстрее EF-database-first, при котором после пары кликов мышкой за тебя всё сразу сгенерено и понятный интерфейс готов к использованию без какой-либо конфигурации и маппингов вообще.
Но, видимо, мои представления не совпадают с мнением большинства. Окей :)

А какое "множество искуственных ограничений" есть в ЕФ кроме приснопамятного enum-support (который, кстати, в версии для .net 4.5 наконец-то присутствует :))?

2 мая 2012 г. 19:18 пользователь Eskat0n <muyo...@gmail.com> написал:

Alexander I. Zaytsev

unread,
May 2, 2012, 11:38:42 AM5/2/12
to dotne...@googlegroups.com


2 мая 2012 г. 20:17 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:

Я, честно говоря, не представляю, какой старт может быть быстрее EF-database-first, при котором после пары кликов мышкой за тебя всё сразу сгенерено и понятный интерфейс готов к использованию без какой-либо конфигурации и маппингов вообще.
Ну вообще речь идет о CodeFirst. Во-вторых, для Datebase First нужна уже спроектированная база, это раз. Третье, для меня создать базу будет медленнее, чем написать сущности, которые потом сами смапятся в базу. 
 
Но, видимо, мои представления не совпадают с мнением большинства. Окей :)
Большинство не всегда право.  

А какое "множество искуственных ограничений" есть в ЕФ кроме приснопамятного enum-support
Этого не достаточно? Ок, тогда еще один минус - нельзя мапить свои функции (например экстеншн методы) в функции базы (в NH - можно). 
 
(который, кстати, в версии для .net 4.5 наконец-то присутствует :))?
Только самого .net 4.5 еще нет. Кстати, раз уж зашла речь про .net 4.5 мы опять видим, что M$ насаждает свои технологии и инструменты - заставляет покупать новую среду для новой платформы.

Artur Drobinskiy

unread,
May 2, 2012, 12:51:35 PM5/2/12
to dotne...@googlegroups.com


2 мая 2012 г. 20:17 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:

Я, честно говоря, не представляю, какой старт может быть быстрее EF-database-first, при котором после пары кликов мышкой за тебя всё сразу сгенерено и понятный интерфейс готов к использованию без какой-либо конфигурации и маппингов вообще.
Ну вообще речь идет о CodeFirst. Во-вторых, для Datebase First нужна уже спроектированная база, это раз. Третье, для меня создать базу будет медленнее, чем написать сущности, которые потом сами смапятся в базу. 
Возможно, я спроектировал своё знакомство с ЕФ на текущую ситуацию.. ну и казалось естественным, что первые пробы ОРМ будут по уже существующей БД.
Со своей стороны основые плюсы ЕФ я вижу именно в случаях database-first подходов.
 
 
Но, видимо, мои представления не совпадают с мнением большинства. Окей :)
Большинство не всегда право.  

А какое "множество искуственных ограничений" есть в ЕФ кроме приснопамятного enum-support
Этого не достаточно? Ок, тогда еще один минус - нельзя мапить свои функции (например экстеншн методы) в функции базы (в NH - можно). 
Ну под термином "множество ограничений" я обычно понимаю больше, чем одно, вот любопытно стало уточнить. Дай, пожалуйста, ссылку, какую именно фичу НХ ты имеешь ввиду, я или недопонял, или не сталкивался с таким.
 
 
(который, кстати, в версии для .net 4.5 наконец-то присутствует :))?
Только самого .net 4.5 еще нет. Кстати, раз уж зашла речь про .net 4.5 мы опять видим, что M$ насаждает свои технологии и инструменты - заставляет покупать новую среду для новой платформы.
Есть в бета-версии. Про насаждение - это уже полный оффтоп :) Есть бесплатные инструменты. За удобство - платим. 

Alexander I. Zaytsev

unread,
May 2, 2012, 1:29:08 PM5/2/12
to dotne...@googlegroups.com


2 мая 2012 г. 22:51 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:



2 мая 2012 г. 20:17 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:

Я, честно говоря, не представляю, какой старт может быть быстрее EF-database-first, при котором после пары кликов мышкой за тебя всё сразу сгенерено и понятный интерфейс готов к использованию без какой-либо конфигурации и маппингов вообще.
Ну вообще речь идет о CodeFirst. Во-вторых, для Datebase First нужна уже спроектированная база, это раз. Третье, для меня создать базу будет медленнее, чем написать сущности, которые потом сами смапятся в базу. 
Возможно, я спроектировал своё знакомство с ЕФ на текущую ситуацию.. ну и казалось естественным, что

 
первые пробы ОРМ будут по уже существующей БД.
Ерунда какая. 
 
Со своей стороны основые плюсы ЕФ я вижу именно в случаях database-first подходов.
А нафига тогда парни стараются, делают CF, и прочие персистент игнорансы?
 
Но, видимо, мои представления не совпадают с мнением большинства. Окей :)
Большинство не всегда право.  

А какое "множество искуственных ограничений" есть в ЕФ кроме приснопамятного enum-support
Этого не достаточно? Ок, тогда еще один минус - нельзя мапить свои функции (например экстеншн методы) в функции базы (в NH - можно). 
Ну под термином "множество ограничений" я обычно понимаю больше, чем одно, вот любопытно стало уточнить. Дай, пожалуйста, ссылку, какую именно фичу НХ ты имеешь ввиду, я или недопонял, или не сталкивался с таким.

Помечаешь метод, как [LinqExtensionMethod] и его вызовы транслируются в вызов SQL-функции.
 
 
(который, кстати, в версии для .net 4.5 наконец-то присутствует :))?
Только самого .net 4.5 еще нет. Кстати, раз уж зашла речь про .net 4.5 мы опять видим, что M$ насаждает свои технологии и инструменты - заставляет покупать новую среду для новой платформы.
Есть в бета-версии.
Спасибо, я подожду релиза.
 
Про насаждение - это уже полный оффтоп :) Есть бесплатные инструменты. За удобство - платим. 
Ну, какбэ я студией пользуюсь только из-за того, что для нее есть решарпер. Платить за новую студию ради async/await че-то не хочется. Вряд ли они targeting-pack для .NET 4.5 для 2010 студии выпустят. 

Alexander Byndyu

unread,
May 3, 2012, 1:23:27 AM5/3/12
to dotne...@googlegroups.com
Артур,

Грубый пример:

В сложных случаях, конечно, вьюмоделька растет за счет результатов вычислений/операций внутри контроллера.
public class IndexViewModel {
    public Project Project {get;set;}
    public List<Users> AllUsers {get;set;} 
}

Здесь IndexViewModel уже не доменный объект, а как раз модель для передачи во View. Я так понял вы добавляете в нее вычисляемые поля, флаги и т.п., а также она содержит доменные объекты.

Может быть, что в списке List<Users> для каждого пользователя вам нужно будет вычислить какое-то поле, например, IsPaidAccessEnabled, которое необходимо только для отображения. Тогда вы сделаете, что-то типа:

public class IndexViewModel {
    public Project Project {get;set;}
    public List<UserViewModel> AllUsers {get;set;} 
}

Так?

--
Best regards,
Byndyu Alexander

Phone: +7 (904) 305 5263
Skype: alexander.byndyu
Blog: http://blog.byndyu.ru
Twitter: alexanderbyndyu



2 мая 2012 г. 16:01 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:

Андрей Чистяков

unread,
May 3, 2012, 3:08:11 AM5/3/12
to dotnetconf

On 3 май, 08:23, Alexander Byndyu <alexander.byn...@gmail.com> wrote:

> Может быть, что в списке List<Users> для каждого пользователя вам нужно
> будет вычислить какое-то поле, например, IsPaidAccessEnabled, которое
> необходимо только для отображения. Тогда вы сделаете, что-то типа:
>
> public class IndexViewModel {
>
>     public Project Project {get;set;}
>

>     public List<*UserViewModel*> AllUsers {get;set;}
>
> }
>
> Так?

Я делаю именно так (с тех пор как меня просветили в ответ на мой
вопрос http://groups.google.com/group/dotnetconf/browse_thread/thread/c28b811257f09ef5,
за что еще раз спасибо всем участникам :). Думаю, может быть даже так:

public class IndexViewModel {
public *ProjectViewModel* Project {get;set;}
public List<*UserViewModel*> AllUsers {get;set;}
}

потому что возможно, что нам не нужен весь Project целиком в этом
представлении, может быть мы только название этого проекта показываем
где-нибудь в заголовке.

Действительно гораздо удобнее использовать специализированные вью-
модели вместо объектов домена. А больше всего мне нравится, что
благодаря этому домен и UI оказываются гораздо слабее связаны между
собой.

Artur Drobinskiy

unread,
May 3, 2012, 3:17:27 AM5/3/12
to dotne...@googlegroups.com
Здесь IndexViewModel уже не доменный объект, а как раз модель для передачи во View.

Конечно, я и писал, что
 только в сложных ситуациях модель не является просто композицией доменных объектов.
То есть модель - это не один доменный объект в любом случае, а несколько, их композиция.


для каждого пользователя вам нужно будет вычислить какое-то поле, например, IsPaidAccessEnabled
public List<UserViewModel> AllUsers {get;set;} 
 
Да, весьма вероятно. Но на моей практике это достаточно редкая ситуация. Чаще такие поля либо заслуживают быть помещенными в домен (если они вычисляются на основе других полей сущности User и используются во многих местах, то есть имеют доменный смысл), либо это простая вьюшная логика (типа, не знаю, цвета колонки), в этом случае она и находится во вью.


3 мая 2012 г. 12:23 пользователь Alexander Byndyu <alexande...@gmail.com> написал:

Artur Drobinskiy

unread,
May 3, 2012, 3:18:59 AM5/3/12
to dotne...@googlegroups.com



2 мая 2012 г. 22:51 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:



2 мая 2012 г. 20:17 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:

Я, честно говоря, не представляю, какой старт может быть быстрее EF-database-first, при котором после пары кликов мышкой за тебя всё сразу сгенерено и понятный интерфейс готов к использованию без какой-либо конфигурации и маппингов вообще.
Ну вообще речь идет о CodeFirst. Во-вторых, для Datebase First нужна уже спроектированная база, это раз. Третье, для меня создать базу будет медленнее, чем написать сущности, которые потом сами смапятся в базу. 
Возможно, я спроектировал своё знакомство с ЕФ на текущую ситуацию.. ну и казалось естественным, что

 
первые пробы ОРМ будут по уже существующей БД.
Ерунда какая. 
 
Со своей стороны основые плюсы ЕФ я вижу именно в случаях database-first подходов.
А нафига тогда парни стараются, делают CF, и прочие персистент игнорансы?
Для каждой задачи есть своё наилучшее решение. Есть ситуации, когда у одной БД два клиента. В этом случае как минимум в случае одного клиента полный персистанс игноранс не выйдет.

 
 
Но, видимо, мои представления не совпадают с мнением большинства. Окей :)
Большинство не всегда право.  

А какое "множество искуственных ограничений" есть в ЕФ кроме приснопамятного enum-support
Этого не достаточно? Ок, тогда еще один минус - нельзя мапить свои функции (например экстеншн методы) в функции базы (в NH - можно). 
Ну под термином "множество ограничений" я обычно понимаю больше, чем одно, вот любопытно стало уточнить. Дай, пожалуйста, ссылку, какую именно фичу НХ ты имеешь ввиду, я или недопонял, или не сталкивался с таким.

Помечаешь метод, как [LinqExtensionMethod] и его вызовы транслируются в вызов SQL-функции.
Спасибо большое, не знал. 

Alexander I. Zaytsev

unread,
May 3, 2012, 3:27:56 AM5/3/12
to dotne...@googlegroups.com


3 мая 2012 г. 13:17 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:

Здесь IndexViewModel уже не доменный объект, а как раз модель для передачи во View.

Конечно, я и писал, что
 только в сложных ситуациях модель не является просто композицией доменных объектов.
То есть модель - это не один доменный объект в любом случае, а несколько, их композиция.


для каждого пользователя вам нужно будет вычислить какое-то поле, например, IsPaidAccessEnabled
public List<UserViewModel> AllUsers {get;set;} 
 
Да, весьма вероятно. Но на моей практике это достаточно редкая ситуация. Чаще такие поля либо заслуживают быть помещенными в домен (если они вычисляются на основе других полей сущности User и используются во многих местах, то есть имеют доменный смысл), либо это простая вьюшная логика (типа, не знаю, цвета колонки), в этом случае она и находится во вью.

Приведу пример: у вас есть такая "ViewModel", в которую пропиханы сохраняемые классы, и в один прекрасный момент другой разработик захочет в этой вьюхе использовать навигационное поле:

@foreach (var user in Model.AllUsers) {
@* some logic*@

Products count: @user.Products.Count()

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

При этом, если у вас контекст уничтожается после отрисовки вью, то вы получите SELECT N+1. Если же контекст уничтожается после вызова экшена, то вы получите LazyLoadException.

При первом варианте - все хорошо и замечательно - ваш программист счастлив и закоммитил код.

Во втором варианте он протестировал и увидел, что это не работает (а бывает, что просто залез на продакшен и поправил вьюшку там), добавил Include(x=>x.Products) в запрос. Итого, везде, где у вас будет использоваться этот запрос, будет делаться join к Product, который, возможно, не нужен.

Alexander I. Zaytsev

unread,
May 3, 2012, 3:30:07 AM5/3/12
to dotne...@googlegroups.com


3 мая 2012 г. 13:18 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:




2 мая 2012 г. 22:51 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:



2 мая 2012 г. 20:17 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:

Я, честно говоря, не представляю, какой старт может быть быстрее EF-database-first, при котором после пары кликов мышкой за тебя всё сразу сгенерено и понятный интерфейс готов к использованию без какой-либо конфигурации и маппингов вообще.
Ну вообще речь идет о CodeFirst. Во-вторых, для Datebase First нужна уже спроектированная база, это раз. Третье, для меня создать базу будет медленнее, чем написать сущности, которые потом сами смапятся в базу. 
Возможно, я спроектировал своё знакомство с ЕФ на текущую ситуацию.. ну и казалось естественным, что

 
первые пробы ОРМ будут по уже существующей БД.
Ерунда какая. 
 
Со своей стороны основые плюсы ЕФ я вижу именно в случаях database-first подходов.
А нафига тогда парни стараются, делают CF, и прочие персистент игнорансы?
Для каждой задачи есть своё наилучшее решение. Есть ситуации, когда у одной БД два клиента. В этом случае как минимум в случае одного клиента полный персистанс игноранс не выйдет.

Под парнями я имел ввиду индусов из M$. 

Если абстрагироваться от данных неправильными абстракциями - то конечно не выйдет, причем в любом случае. 

Artur Drobinskiy

unread,
May 3, 2012, 3:55:08 AM5/3/12
to dotne...@googlegroups.com


3 мая 2012 г. 14:27 пользователь Alexander I. Zaytsev <hazzik...@gmail.com> написал:

С batch-size SELECT N+1 не будет.
Если в итоге это не отражается на производительности (если User.Products это товары в корзине и их в большинстве случае мало) - то счастливы все.

Если производительность пострадала, то "другой разработчик" должен был думать головой. Впрочем, с помощью профайлера это будет скорее всего замечено позже.
Я сторонник прежде всего подхода "думать головой", а не ограничений, которые усложняют простые операции.
А накосячить всегда можно.

Alexander I. Zaytsev

unread,
May 3, 2012, 4:27:53 AM5/3/12
to dotne...@googlegroups.com


3 мая 2012 г. 13:55 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:



3 мая 2012 г. 14:27 пользователь Alexander I. Zaytsev <hazzik...@gmail.com> написал:



3 мая 2012 г. 13:17 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:

Здесь IndexViewModel уже не доменный объект, а как раз модель для передачи во View.

Конечно, я и писал, что
 только в сложных ситуациях модель не является просто композицией доменных объектов.
То есть модель - это не один доменный объект в любом случае, а несколько, их композиция.


для каждого пользователя вам нужно будет вычислить какое-то поле, например, IsPaidAccessEnabled
public List<UserViewModel> AllUsers {get;set;} 
 
Да, весьма вероятно. Но на моей практике это достаточно редкая ситуация. Чаще такие поля либо заслуживают быть помещенными в домен (если они вычисляются на основе других полей сущности User и используются во многих местах, то есть имеют доменный смысл), либо это простая вьюшная логика (типа, не знаю, цвета колонки), в этом случае она и находится во вью.

Приведу пример: у вас есть такая "ViewModel", в которую пропиханы сохраняемые классы, и в один прекрасный момент другой разработик захочет в этой вьюхе использовать навигационное поле:

@foreach (var user in Model.AllUsers) {
@* some logic*@

Products count: @user.Products.Count()

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

При этом, если у вас контекст уничтожается после отрисовки вью, то вы получите SELECT N+1. Если же контекст уничтожается после вызова экшена, то вы получите LazyLoadException.

При первом варианте - все хорошо и замечательно - ваш программист счастлив и закоммитил код.

Во втором варианте он протестировал и увидел, что это не работает (а бывает, что просто залез на продакшен и поправил вьюшку там), добавил Include(x=>x.Products) в запрос. Итого, везде, где у вас будет использоваться этот запрос, будет делаться join к Product, который, возможно, не нужен.

С batch-size SELECT N+1 не будет.
Если в итоге это не отражается на производительности (если User.Products это товары в корзине и их в большинстве случае мало) - то счастливы все.
Ок, расскажите это ребятам из EF:) Там нет такой штуки. User.Products - это просто "УЧЕБНЫЙ ПРИМЕР" в реале это может быть любая коллекция любой длины.
 
Если производительность пострадала, то "другой разработчик" должен был думать головой.
Кому должен? Вы тут используете будущее в прошедшем - машину времени пока не придумали, и предотвращать ошибки прошлого еще никто не научился. Это можно будет исправить в будущем, но тут другой вопрос.
 
Впрочем, с помощью профайлера это будет скорее всего замечено позже.
И вопрос такой: насколько позже? Когда пользователи начнут жаловаться, что всё медленно?
 
Я сторонник прежде всего подхода "думать головой", а не ограничений, которые усложняют простые операции.
Ну, _небольшое_ усложнение с использованием ViewModel облегчает жизнь в будущем.
 
А накосячить всегда можно.

Artur Drobinskiy

unread,
May 3, 2012, 4:42:29 AM5/3/12
to dotne...@googlegroups.com
Саша, я не пытаюсь тебя переубедить и уж тем более не пытаюсь сказать, что твой подход плох.
Мой подход другой. В других условиях и при других задачах, возможно, я бы склонялся к другим подходам.

В моих условиях не было проблем, которые бы убедили меня сделать это самое _небольшое_ усложнение. Возможно "пока не было". Возможно, все мои случаи настолько простые, что и не будет.

Я использую "полноценные" вью модели как в примере, который описал Саша Бындю. В сложных случаях. Использовать их постоянно - поводов не было.
Подобная дискуссия у меня в мозгу уже проходила. Я сам себя не убедил на always-view-mo :)

По поводу ЕФ - в проектах, к которым применима эта дискуссия, я использую НХ.
У ЕФ, в рамках моей деятельности, зона применимости другая.

3 мая 2012 г. 15:27 пользователь Alexander I. Zaytsev <hazzik...@gmail.com> написал:

Alexander I. Zaytsev

unread,
May 3, 2012, 4:56:24 AM5/3/12
to dotne...@googlegroups.com
Я просто пытаюсь обнажить проблемы, которые _ВОЗМОЖНО_ возникнут, что бы люди могли прочитать и увидеть их, и уже имея полное представление о плюсах и минусах делали выводы. 

Спор двух опытных программистов для новеньких всегда будет выглядеть как разговор двух физиков ядерщиков (ну да, тут опять время для ссылки на матрицу компетентности). 

3 мая 2012 г. 14:42 пользователь Artur Drobinskiy <artur.dr...@gmail.com> написал:

Саша, я не пытаюсь тебя переубедить и уж тем более не пытаюсь сказать, что твой подход плох.
Мой подход другой. В других условиях и при других задачах, возможно, я бы склонялся к другим подходам.
Конечно другой, и у меня другой. Это же естественно, что цель оправдывает средства, а не наоборот. Т.е. нет смысла стрелять из DDD-пушки по сайту визитке;) 

Alexander Byndyu

unread,
May 4, 2012, 1:14:32 PM5/4/12
to dotne...@googlegroups.com
Написал по этой теме более развернуто  http://blog.byndyu.ru/2012/05/viewmodel-domain-model.html 


--
Best regards,
Byndyu Alexander

Phone: +7 (904) 305 5263
Skype: alexander.byndyu
Blog: http://blog.byndyu.ru
Twitter: alexanderbyndyu



3 мая 2012 г. 14:56 пользователь Alexander I. Zaytsev <hazzik...@gmail.com> написал:
Reply all
Reply to author
Forward
0 new messages