Пример позитивного риска, закончившегося успехом — для сайта электронного магазина было принято решение отказаться от самописного ORM в пользу NHibernate. Понадобилось дополнительно 6 дней, чтобы полностью перевести проект, но потом это сэкономило очень много времени на разработке, когда требования изменились, а один из разработчиков ушел.
Плюсов у доменной модели множество, вы правильно отметили. Минус — модель — это все-таки не данные. Ее не стоит применять там, где вы работаете с плоскими «plain old» данными — статистика и прочее. Типичный пример — OLTP и Reporting: намекните об этом любому разработчику ORM и смотрите, что будет (на всякий случай отойдите в сторону :)
А в целом: хорошая книга от М. Фаулера «Patterns of Enterprise Application Architecture» наглядно разбирается и отвечает на поднятый вопрос. Рекомендую.
Доля правды ваша :) Однако зарулить всех… этих, как их… креотивных директоров в одиночку вряд ли бы удалось. Помните, как у Пелевина?
"– Пойдешь ко мне в штат?
– Кем? – спросил он.
– Криэйтором.
– Это творцом? – переспросил Татарский. – Если перевести?
Ханин мягко улыбнулся.
– Творцы нам тут на х%& не нужны, – сказал он. – Криэйтором, Вава, криэйтором."
Верно. При этом «непоставленный плюс» к карме зачастую оправдывается тем, что «далеко идти до профиля», а вот войти в профиль и поставить «минус» — это всегда близко :)
>> затем забанил всех тех LJ-блоггеров, которые Апача читали.
Какие нехорошие блогеры — читают Апача. Так их, ага :)
>> прекрасно характеризует тот уровень аргументации, который на Хабре общепринят
Я считаю, он вас более чем устраивает — иначе заводить здесь блог и начинать достаточно регулярно в него писать Вам не имело бы смысла.
Спорить не хочу; однако глаз цепляется за заметные противоречия
В отличие от Хабра, в ЖЖ нет возможности оценить комментарий :) Выразить несогласие ответным комментарием можно, а вот грубо оборвать и заставить «заткнуться» — нет.
С аргументами некоторых людей невозможно спорить — например, потому что они правы. Но хозяина блога это не устраивало :) И если этот человек писал Mithgol'у то, с чем тот несогласен, ответные действия незамедлительно следовали в виде ban_set; не только человеку-«иноверцу», но и всем его френдам — так, на всяк.
Т.е. по сути — еще один препроцессор текста, если я правильно понял вас и документацию на сайте.
Однако еще один препроцессор — nesC — на фоне Wiring/С смотрится приятнее. Там есть и модули (аналог объектов/компонент), и интерфейсы (как протоколы компонентов). А это означает более приближенную у ООП парадигму написания кода и более естественную модель повторного использования.
Учитывая, что и там, и там выход препроцессора затем обрабатывается при помощи avr chaintools, есть шанс прикрутить nesC к arduino.
Поставил плюс.
Однако в NHibernate это — только как один из вариантов, используемый для достаточно простых запросов. Для более сложных гораздо приятнее не городить кучу синтаксического мусора, а писать прямо на HQL.
Я думаю, что сказав А, стоит сказать и Б :) Показанная в посте система построения запросов — это пример QBA — «Query By API»:
… запросы конструируются путем использования объектов-запросов, обычно примерно в такой форме:
Query q = new Query();
q.From(«PERSON»).Where( new EqualsCriteria(«PERSON.LAST_NAME», «Smith»));
ObjectCollection oc = QueryExecutor.execute(q);
Здесь запрос основывается не на пустом «шаблоне» выбираемого объекта, а на наборе «объектов-запросов», которые совместно используются для определения объекта в стиле команды, предназначенной для выполнения над базой данных. Несколько критериев комбинируется путем использования некоторой конструкции, обычно соединяющей через «And» и «Or» объекты, каждый из которых содержит уникальный объект-критерий, задающий часть условия выборки. К концу запроса могут быть добавлены вызовы объектов фильтрации/манипулирования, такие как «OrderBy(field-name)» или «GroupBy(field-name)». В некоторых случая эти вызовы методов в действительности ведут в объекты, конструируемые программистом и явно связываемые между собой...
Если вас интересует еще одно лишнее впечатление — в Netbeans есть ощущение «все к месту». Большая часть фич из того, что там есть, мне оказывается нужна, и они в 99% случаев расположены там, где ожидаешь, работают сразу после установки, действуют так, как этого ожидаешь, а при желании настраиваются/обновляются «на раз». С эклипсом ощущение, что IDE взяли, сложили в коробку, сильно потрясли, потом вытащили, и стараются наладить. А из-за этого постоянно что-то не так, что-то поломалось и требует каких-нибудь магических пассов, компонент, плагинов, которые постоянно то не ставятся, то не работают.
А в целом: хорошая книга от М. Фаулера «Patterns of Enterprise Application Architecture» наглядно разбирается и отвечает на поднятый вопрос. Рекомендую.
Какие нехорошие блогеры — читают Апача. Так их, ага :)
>> прекрасно характеризует тот уровень аргументации, который на Хабре общепринят
Я считаю, он вас более чем устраивает — иначе заводить здесь блог и начинать достаточно регулярно в него писать Вам не имело бы смысла.
Спорить не хочу; однако глаз цепляется за заметные противоречия
С аргументами некоторых людей невозможно спорить — например, потому что они правы. Но хозяина блога это не устраивало :) И если этот человек писал Mithgol'у то, с чем тот несогласен, ответные действия незамедлительно следовали в виде ban_set; не только человеку-«иноверцу», но и всем его френдам — так, на всяк.
Однако еще один препроцессор — nesC — на фоне Wiring/С смотрится приятнее. Там есть и модули (аналог объектов/компонент), и интерфейсы (как протоколы компонентов). А это означает более приближенную у ООП парадигму написания кода и более естественную модель повторного использования.
Учитывая, что и там, и там выход препроцессора затем обрабатывается при помощи avr chaintools, есть шанс прикрутить nesC к arduino.
Надеюсь, на этой неделе руки дойдут :)
Однако в NHibernate это — только как один из вариантов, используемый для достаточно простых запросов. Для более сложных гораздо приятнее не городить кучу синтаксического мусора, а писать прямо на HQL.
Отсюда