Model (M-VC) != Domain Model

[Alexander Byndyu]

Всем привет!

Спорный пост 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]

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

Много раз ловил себя на искушении использовать имеющийся объект доменной модели для View, вроде бы все красиво и ничего больше не понадобится... Но через пару релизов кто-то добрый просит "подсветить" колонку или добавить еще одну с накапливаемым итогом и.т.д. В результате таки рождается объект непосредственно под View cо всеми последствиями, в противном случае доменный объект рискует превратиться в нечто монтстрообразное. 

Имхо на каждую V должна быть своя М, путь это будет просто обертка над доменным объектом с одним лишним полем или даже без него, хоть на это и уйдет немного времени на старте, но зато потом гораздо проще рефакторить и сопровождать.

Если в таких объектах включен LazyLoad, то прямо во View я встречаю код: 

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

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

О, это чудо! Контейнер, репозитории, EF и всё работает! 

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

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

а кто заставляет модели играть за разные команды? у меня контроллеры работают ViewModel и DataModel, а с моделью домена работает бизнес-логика, поэтому, модель домена совпадает с моделью в MVC в той части где это не обременительно

[Artur Drobinskiy]

О каждой задаче надо говорить в своём контексте.

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

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

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

Ну и отдельно хотелось бы возразить по поводу:

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

и согласиться с:

модель домена совпадает с моделью в MVC в той части где это не обременительно 

:)

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

Но, конечно, при добавлении полей стоит думать головой, добавлять ли поле в домен. Но думать вообще всегда полезно :)

Артур

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

[Alexander I. Zaytsev]

Привет!

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

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

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

Мне напомнило вот это:

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

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

http://bash.im/quote/416657

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

[Artur Drobinskiy]

У меня достаточно опыта с этими реализациями, чтобы так заявлять.

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

Я одно время работал с Юнити еще даже версии 1.2 - всё было замечательно. ЕФ в отдельных задачах круче/проще/быстрее НХ.

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

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

xxx:

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

Смешной пример, но разве было бы лучше, если бы в начальной школе сразу давали комплексные числа?

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

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

[Alexander I. Zaytsev]

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]

Хочу не согласиться.

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

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

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

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

[Artur Drobinskiy]

Я одно время работал с Юнити еще даже версии 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]

Артур,

А вы на 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]

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]

Передаю доменные объекты, да.

У каждой вьюшки своя ВьюМодель, которая, обычно, содержит несколько доменных объектов. Грубый пример:

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]

Не верю, что 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]

Старт с NH (используя FNH) быстрее в разы.

Под "стартом", чтобы не быть неправильно понятым, я понимаю именно порог вхождения. Первый проект, знакомство с технологией.

"Старт" можно еще трактовать как запуск проекта "с нуля", но я не это имел ввиду в вопросах и ответах.

[Eskat0n]

Порог вхождения в 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]

Я, честно говоря, не представляю, какой старт может быть быстрее EF-database-first, при котором после пары кликов мышкой за тебя всё сразу сгенерено и понятный интерфейс готов к использованию без какой-либо конфигурации и маппингов вообще.

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

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

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

[Alexander I. Zaytsev]

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]

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]

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-функции.

https://github.com/nhibernate/nhibernate-core/blob/master/src/NHibernate.Test/Linq/ExtensionMethods.cs

 

 

(который, кстати, в версии для .net 4.5 наконец-то присутствует :))?

Только самого .net 4.5 еще нет. Кстати, раз уж зашла речь про .net 4.5 мы опять видим, что M$ насаждает свои технологии и инструменты - заставляет покупать новую среду для новой платформы.

Есть в бета-версии.

Спасибо, я подожду релиза.

 

Про насаждение - это уже полный оффтоп :) Есть бесплатные инструменты. За удобство - платим. 

Ну, какбэ я студией пользуюсь только из-за того, что для нее есть решарпер. Платить за новую студию ради async/await че-то не хочется. Вряд ли они targeting-pack для .NET 4.5 для 2010 студии выпустят. 

[Alexander Byndyu]

Артур,

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

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

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> написал:

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

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]

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

Конечно, я и писал, что

 только в сложных ситуациях модель не является просто композицией доменных объектов.

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

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

public List<UserViewModel> AllUsers {get;set;} 

 

Да, весьма вероятно. Но на моей практике это достаточно редкая ситуация. Чаще такие поля либо заслуживают быть помещенными в домен (если они вычисляются на основе других полей сущности User и используются во многих местах, то есть имеют доменный смысл), либо это простая вьюшная логика (типа, не знаю, цвета колонки), в этом случае она и находится во вью.

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

[Artur Drobinskiy]

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-функции.

https://github.com/nhibernate/nhibernate-core/blob/master/src/NHibernate.Test/Linq/ExtensionMethods.cs

Спасибо большое, не знал. 

[Alexander I. Zaytsev]

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]

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]

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

С batch-size SELECT N+1 не будет.

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

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

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

А накосячить всегда можно.

[Alexander I. Zaytsev]

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]

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

Мой подход другой. В других условиях и при других задачах, возможно, я бы склонялся к другим подходам.

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

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

Подобная дискуссия у меня в мозгу уже проходила. Я сам себя не убедил на always-view-mo :)

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

У ЕФ, в рамках моей деятельности, зона применимости другая.

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

[Alexander I. Zaytsev]

Я просто пытаюсь обнажить проблемы, которые _ВОЗМОЖНО_ возникнут, что бы люди могли прочитать и увидеть их, и уже имея полное представление о плюсах и минусах делали выводы. 

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

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

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

Мой подход другой. В других условиях и при других задачах, возможно, я бы склонялся к другим подходам.

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

[Alexander Byndyu]

Написал по этой теме более развернуто  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> написал: