Spring Framework 2.5

>> То есть? Не понял мысли? Если про версию yaws - то 1.70. >В смысле Erlyweb или все руками?

Все руками. Это был небольшой такой своеобразный add-on к ejabberd для просмотра архива сообщений.

>Пример.

загрузить из базы корректную (то есть правильно связанную - или вы исключительно на метамодели самой базы (foreign keys) будете всё строить?) модель для отображения в морде. Да модель можно сконфигурировать где нибудь - но это уже бизнес-логика.

>Нет. Для борьбы со сложностью. По моему это Гамма сказал, что никогда в жизни связывани объектных моделей с реальным миром не приносило ему никакой пользы.

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

>Ничего объектного в валидации и констрейнтах нет.

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

>Нет в условии задачи. Для вас открытие что ООП - а) не подходит для всех возможных нужд, b) не решает любые задач лучше всего, c) для этого и не предназначено?

задачу ставили Вы сами. В том числе и относительно Алана Кея. Кстати - неужели в смолтоке нет ни одного ОРМа? И смотря что понимать под ООП... конечно ООП не предел, но и не никчемная вещь а вполне себе технология. Как минимум для прикладого софта очень неплохая. Того самого прикладного где есть разная такая бизнес-логика.

>В данной задаче объектные принципы ничего не дают.

Это тоже смотря кому не дают. А что нибудь отнимают? Что же?

Но это всё так сказать флейма ради... А вот если серьезно - лучше что нибудь конструктивное предложить можете? Желательно с реальными прецедентами. Причем лучше в смысле того что Вам не нравится в ООП и ОРМов.

>Если NULL-значения возможны - нужно использовать nullable-типы (т.е. обертки Integer/Long/...).

если честно, не вижу проблемы в том чтобы тело метода начать с декларации в стиле

assert someInteger!=null;

это если так рассуждать ("не нулл == примитив") то что тогда делать с полями типа "char[10] not null" ? думаю что даже "void setField(char[10] value)" не очень поможет - массив это уже нуллейбл объект. проверять всё равно придется. ассёрт самое то - чуть что не так, вот вам ексепшин.

>ORM вообще нужен для того чтобы данные из базы представлять в объектном виде. Состояние объектов долдно точно соответсвовать констрейнтам наложеным на базу. Если не соотвествует - это как база данных без констрейнтов. ЗАчем нужны констрейнты расказывать? Или у вас объекты не имеют корнстрайнтов внутри себя и являются таким себе типизированным хешом без намека на необходимость валидного состояния?

Батенька, вы бред несете. Состояние объектов не обязано соответствовать всем констрейнтам базы - всякие check'и и валидирующие триггеры на слой приложения вытащить сложно. Поэтому при нарушении констрейнтов - будем получать exception'ы при коммите.

НО!

Точно такая же проблема и обычного SQL+ResultSet. То есть, получаем мы ResultSet: "select * from blah where something<10". Отдаем результат в GUI (на веб-страницу или толстый клиент). Ну и пользователь решает что-нибудь обновить: "update blah set anything=20 where id=12". Но в result-set'е НЕТ информации о всех констрейнтах и проверках в базе! И при коммите пользователь получит по лбу исключением "'anything' value out of range".

С ORM ситуация ну абсолютно такая же. За исключением того, что пользователь получит не нетипизированый ResultSet, а хороший и удобный List<Blah>.

> Ну таки чё, тестить кто будет или так поумничали и разбежались?

Давно уж все потестили: http://rsdn.ru/Forum/message/2739549.flat.aspx Пыхыпы сосет причмокивая.

>> И где ты это увидел? > Добавил.

То есть предлагается мало того, что одну таблицу испохабить, так еще и по зависимым это растащить? Ну-ну, давай, удачи. :D

а по поводу "вредности" ОРМов хочу добавить что даже если ОРМ и "зло" то "зло " необходимое... просто не нужно использовать его там (точнее не там) и так (точнее не так) где он вреден. Задача ОРМа весьма узкая - дата-лейер, персистенция. всё. всё остальное задача других уровней и паттернов. смешивать и передавать напрямую непосредственно модель из одного уровня в другой - ССЗБ. классический пример я уже приводил: ORM vs MVC. Как правило не долго думая в качестве модели (ну уж в составе модели так точно) используют непосредственно замапленные объекты. А потом отгребают кучу побочных еффектов. А откуда позвольте спросить следует что модель дата лейера должна быть непосредственно адекватна модели представления? Как правило между моделями дата лейера и презентейшина есть очень существенные различия. Настолько существенные что просто нет особого смысла использовать непосредственно объекты из дата лейера. А вот что имеет смысл - провести трансформацию данных из объектов дата лейера в модель представления путем __необходимого_копирования_ (!!!). И всё. Дальше можете делать с новой моделью всё что вам будет угодно ни о чем не беспокоясь. Побочных еффектов не будет. И загрузите вы из базы ровно то что вам будет нужно не больше и не меньше. Хоть по сети передавайте, хоть обрезайте текст, хоть в формочках редактируйте.
Кстати о формочках - еще одна причина разделения моделей дата лейера и презентейшина заключается в том что в процессе ввода данных в формочки и последующей валидации этого ввода необходимо сохранять отображение даже принципиально неверных данных (например не того типа - буквы вместо цифр например) - иначе пользователь просто не поймет что он сделал не правильно. естественно выделить красным там цветом эти буквы и сказать ему - введите пожалуйста цифры. и вот скажите мне - как это сделать если пытаться сохранять форму непосрественно в модель данных ОРМа? уверен что никак. а дело все в том что и нет в этом никакой необходимости. ну покажите мне где нибудь пример из спринга где так делается? везде форма имеет _свою_модель. которая _после_ валидации трансформируется копированием в другую уже модель которая и передается в дао.

> Т.е. идеальный веб-сервер, имеющий абсолютно нулевой оверхед, ускорил бы PHP-версию примерно на 15%. Ну еще процентов 50% можно какими-нибудь тюнингами добрать.

> Но Java-то в этом случае все равно будет примерно в 10 раз быстрее!

Да откройте же вы, наконец, для себя PHP accelerator! И получите свои недостающие 10 раз... Ну устроен php так. Котлеты у него отдельно, кэш байткода отдельно. Зачем годами повторять одну и ту же глупость про отставание в 10 раз?

>Да откройте же вы, наконец, для себя PHP accelerator! И получите свои недостающие 10 раз... Ну устроен php так. Котлеты у него отдельно, кэш байткода отдельно. Зачем годами повторять одну и ту же глупость про отставание в 10 раз?

mod_php прекрасно кэширует байт-код, так что не надо.

Нужны акселераторы, делающие JIT-компиляцию в нативный код. Нормальных бесплатных таких нет. Ну а дальше будет уже борьба компиляторов, в которой у Java примерно десятилетнее преимущество.

Кстати, если PHP JIT-компилировать в Java-байт-код (с помощью http://www.caucho.com/resin-3.0/quercus/), то получим примерно пятикратное ускорение в части тестов.

> Большая часть перечисленного в SQLAlchemy есть:
Все это есть в любом уважающем ORM, не удивил.
Но вот поддержки сложных схем развертывания приложения и fail over у нее нет

> И на глазах у изумленной публики Ваше "на голову выше" рушится как хрупкий карточный домик.
Только в ваших глазах. Вы ведь ничего вокруг больше видеть не хотите.

>Давно уж все потестили: http://rsdn.ru/Forum/message/2739549.flat.aspx Пыхыпы сосет причмокивая.

Причем тут пых-пых вообще? Разговор идет за Django и Spring.

>Большая часть перечисленного в SQLAlchemy есть: >Все это есть в любом уважающем ORM, не удивил. >Но вот поддержки сложных схем развертывания приложения и fail over у >нее нет

Django не использует SQLAlhemy, у нее свой ORM.

>Причем тут пых-пых вообще? Разговор идет за Django и Spring.

При том, что PHP и Python имеют сравнимую скорость работы.

Анонимус, что запостал толковое описалово 'по поводу "вредности" ОРМов': Вы где работаете и живёте? Хотел бы с вами как-нибудь встретиться и пообщатся.

Можете отвечать на мейл: rodion (ат) generation-p.com

>При том, что PHP и Python имеют сравнимую скорость работы.

Умница, возьми с полки пирожок, и ложись спать. Завтра в садик рано вставать.

>Может просто изначально проектировать нормально?

ты или не понимаешь о чем разговор или... У тебя таблицы без связей? Или объекты без связей?

>Проектируй системы, вызовы, кэш с учетом отсутствия lazy.

Ты знаешь что такое Lazy?

>Зачем? Уже все написано. Только пользовать нужно по назначению.

Название?

>Потому-что стояла четкая задача куторую кошерные гибернейты и EJB2.0/3.0 не покрывали.

Очень интересно услышать эту задачу.

>А с SQL в iBATIS не нужно ковыряться. С ними можно работать.

Гениально! В конце концов все свелось к old plain sql только в конфиге ibatis?

>В случае Hibernate либо все данные попадут в память сервера приложений, либо будет несчадно томозить. Его механизмов оптимизации в нашем случае недостаточно.

Ага. А с чего оно будет несчадно тормозить или в память попадать? Как ты там сказал проектировать надо грамотно?

Вам вообще орм нужен если идет такой жесткий датамайнинг?

>iBATIS делает mapping из ResultSet в POJO?

Это делает кто угодно без всяких ибатисов и не называет себя при этом ORM. Тебя не смущает название ORM? Object/_Relational_ Mapping. Знаешь что такое Relation в теории БД? Совсем не резалтсет.

>Каким боком iBATIS не ORM?

почитай на сайте iBatis. Они себя так не называют. Может потому что одна из ключевых концепций ORM - это абстракция разработчика от SQL в то время как iBatis от JDBC/ADO API и _использование_ sql?

>А термин "dependency injection", кстати, даже и изобрел.

Сказки венского леса. Спринг нарисовался в 2002 году. Проект Авалон был с 99 уже в Апаче. Я не сомневаюсь что есть и более ранние упоминания.

> Можете отвечать на мейл: rodion (ат) generation-p.com

Это что шутка? Я отправил Вам емейл и получил от "Вас" ответ
PERM_FAILURE: SMTP Error (state 13): 550 Unrouteable address

Если Вы действительно хотите пообщаться (насчет встречь чесно говоря я пока настроен не очень - хотя бы потому что просто нет времени свободного много) то уточните свой адрес. Или это просто у Вас такая защита от спама? )

>модель для отображения в морде.

Это не бизнес-логика. это отображение данных.

http://en.wikipedia.org/wiki/Business_logic

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

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

>И смотря что понимать под ООП...

ООП имеет весьма четкий набор характеристик. И он не заканчивается на возможности описать структурный элемент типа class/object.

>Как минимум для прикладого софта очень неплохая. Того самого прикладного где есть разная такая бизнес-логика.

Никто и не говорит что плохая. Но в данной постаноке задачи не нужная.

>А вот если серьезно - лучше что нибудь конструктивное предложить можете?

Дело не в том лучше или хуже. Просто приводить Объектность как аргумент в пользу орма не верно потому, что сам ORM не объектная технология. От того, что в той же жабе ормы строятся на классах не проистекает, что это так должно быть или что оно объектное (чтобы программа имеет ОО дизайн совсем недостаточно пользоваться классами). В других языках они могут строится на именованых хешах, структурах,в динамических языках именно вообще только так ормы и делаются. А почему ORM ни разу не ООП читать тут:

http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch

Это по поводу моделей. А по сути в структурах с которым иработает ОРМ вы не найдете практически никаких объектных характеристик.

Это способ постинга е-мэйла на публичных форумах: у правильного адреса "@" заменяется на " (ат) ". Цель этого упражнения - не допустить (по возможности), чтобы спаммерские роботы занесли мой адрес в свои базы. Так что: echo "rodion (ат) generation-p.com" | sed 's/ (ат) /@/' даст Вам правильный адрес.

>Это способ постинга е-мэйла на публичных форумах: у правильного адреса "@" заменяется на " (ат) ". Цель этого упражнения - не допустить (по возможности), чтобы спаммерские роботы занесли мой адрес в свои базы. Так что: echo "rodion (ат) generation-p.com" | sed 's/ (ат) /@/' даст Вам правильный адрес.

ну я вроде не совсем еще деградировал. естественно все необходимые преобразования адреса были выполненны. как вы думаете - почтовый клиент вообще будет пытаться отправлять почту на адрес где вместо @ будет стоять (at) ? Я чесно говоря даже еще и не пробовал делать подобное но подозреваю что до ответов от SMTP демона дело не дойдет.

Причем я естественно проверил что такое generation-p.com - ресурс вроде приличный, подозрений не вызывает. Но вот почта по указанному адресу не идёт почему то... вобщем, если будет о чем говорить то укажите какой нибудь другой интерфейс - instance messaging какой нибудь например - или посмотрите почему ни с gmail ни с hotmail почта не идёт к вам.

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

> У тебя таблицы без связей? Или объекты без связей?
Со связями. И таблицы и объекты.

> Название?
Это к Google, пожалуйста.

> Очень интересно услышать эту задачу.
Озвучена

> В конце концов все свелось к old plain sql только в конфиге ibatis?
если за SQL вы больше ничего в iBATIS не видите это ваши проблемы.

> А с чего оно будет несчадно тормозить или в память попадать?
Попробуйте, почитайте как работает Hibernate внутри. Его механизмы оптимизации.

> Как ты там сказал проектировать надо грамотно?
Да. Именно так. Не только проектировать, но и выбирать инструмент под задачу.

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

> Знаешь что такое Relation в теории БД?
Это такой вопрос да? :)

> ORM - это абстракция разработчика от SQL в то время как iBatis от JDBC/ADO API и _использование_ sql?
Простите. А у вас сколько человек в команде? И что, совсем нет DBA? А, ну да. Зачем он нужен, если Hibernate (ORM) сам все сделает, оптимизирует и даже таблички в базе создаст!

>Умница, возьми с полки пирожок, и ложись спать. Завтра в садик рано вставать.

Осмысленый ответ будет? Чего стоит взять код на PHP из теста и сделать версию на Питоне?

Ведь Питон - это такой простой язык, что там все это за минуту пишется. Так ведь?

>Батенька, вы бред несете.

Я не один такой - представляете? http://en.wikipedia.org/wiki/Object-relational_mapping

>Поэтому при нарушении констрейнтов - будем получать exception'ы при коммите.

Очень это полезные эксепшены. Пользовтель в форме ввел данные, и получил исключение при коммите. Догадайтесь почему?

>С ORM ситуация ну абсолютно такая же. За исключением того, что пользователь получит не нетипизированый ResultSet, а хороший и удобный List<Blah>.

И удобство его состоит в том, что туда бойду всякую запихнуть нельзя, потому что он является "базой в виде объектов" и проверяет констрейнты именно так как надо, не давая программисту написать лажу в одном месте, чтобя она вылетела при коммите и он разгребался, а где собственно произошла ошибка. Одно из достоинств орма в этом и состоит - в возможности корректно извлекать данные и записывать их. В грамотно написанной программе с ОРМом SQLException вылетать должен только в одном случае CannotConnect. А не присвоили 0 закомитили, атгребли, почесали репу и написали в коменте "нуля тут не присваивать". Нет напишут assert который жестко даст по рукам при попытке нарушить инвариант базы в объектах. Иначе будете ловить исключения с датабейс леера так часто что в орме никакого смысла не будет, даже эстетического.

>То есть предлагается мало того, что одну таблицу испохабить

Что испохабить? Это первичный ключ.

>>А термин "dependency injection", кстати, даже и изобрел. >Сказки венского леса. Спринг нарисовался в 2002 году. Проект Авалон был с 99 уже в Апаче. Я не сомневаюсь что есть и более ранние упоминания.

Тем не менее, _термин_ dependency injection был изобретен Фаулером под впечатлением от Спринга: http://www.theserverside.com/news/thread.tss?thread_id=23358

Ну и Авалон со Спрингом немного в разных весовых категориях.

Ладно,

давайте перестанем друг друга подозревать в деградировании :). Вы правы: действительно родион@ не работает (убью админа в четверг, как только доберусь до него физически). Зато работает rodney@ (я проверил - с gmail'а почта доходит).

Причина контакта - позиция мне кажется очень здравой, и Вы смогли её очень толково (и сравнительно кратко) расписать. Может, сможем быть друг другу полезны.

>А потом отгребают кучу побочных еффектов.

Именно.

>Это не бизнес-логика. это отображение данных.

http://en.wikipedia.org/wiki/Business_logic

Идем по ссылке и читаем в первом же предложении.

Business logic is a non-technical term generally used to describe the functional algorithms which handle information exchange between a database and a user interface.

Что я сказал не правильно? Построение модели _для_ отображения данных это и есть в частности бизнес-логика (не только это конечно но и это тоже). Само же _отображение_данных_ это уже совсем другой уровень, а именно - view. Если говорить в терминах MVC то бизнес-логика это controller. Вы опять не согласны? Хорошо, расскажите пожалуйста что такое контроллер и чем он занимается, если не иплементит бизнес-логику путем построения модели для вью? Что такое "строить модель"? Дайте определение этого этапа. Вы хотите сказать что контроллеру не нужен нижележащий уровень ДАО и он (контроллер) должен самостоятельно коннектиться к базе, генерировать запросы, извлекать дата-сеты и тд и тп? Зачем тогда нужен контроллер? Почему не прямо в JSP дернуть базу и показать табличку? Вы именно о такой "архитектуре" мечтаете что ли? Так в чем проблема - делайте именно так :) кто мешает то?

> Структуры данных не обязательно представляются объектными деревьями.

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

>ООП имеет весьма четкий набор характеристик. И он не заканчивается на возможности описать структурный элемент типа class/object.

а кто утверждает что заканчивается?? и если не заканчивается то разве и не начинается?? помоему Вы несколько сами себе противоречите....

>Никто и не говорит что плохая. Но в данной постаноке задачи не нужная.

Довольно спорное утверждение, имхо. Обоснуйте строго степень её не нужности в данной постановке задачи.

>Дело не в том лучше или хуже. Просто приводить Объектность как аргумент в пользу орма не верно потому, что сам ORM не объектная технология. От того, что в той же жабе ормы строятся на классах не проистекает, что это так должно быть или что оно объектное (чтобы программа имеет ОО дизайн совсем недостаточно пользоваться классами). В других языках они могут строится на именованых хешах, структурах,в динамических языках именно вообще только так ормы и делаются.

вот это уже круто) а на что же тогда мапятся отношения в ОРМе? не на объекты? и от того что на низком уровне объект может быть представлен как хеш он перестает быть объектом? что конкретно нарушается в ООД в случае ОРМов? "это не нужно"? а что нужно? а ООД вообще нужно?

>http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch >Это по поводу моделей.

И что? Ну есть некоторый "когнитивный диссонанс". Что дальше-то? Его вообще везде можно найти, при желании.

>А по сути в структурах с которым иработает ОРМ вы не найдете практически никаких объектных характеристик.

"Объектные характеристики" имеет даже тупой JDBC.

> Что испохабить? Это первичный ключ.

Дурь это, а не ключ

>Со связями. И таблицы и объекты.

Они поднимаются в память или нет?

>Это к Google, пожалуйста.

То есть ты не знаешь?

>Попробуйте, почитайте как работает Hibernate внутри. Его механизмы оптимизации.

Я это не только читал я пробовал SQL генератор переписывать в hibernate для реализации платформы которая не совсем SQL - я знаю как оно работает. После того как hibernate скушал jboss его конечно изрядно выровняли, а до этого он был ужасом летящим на крыльях ночи в потрохах.

>Не только проектировать, но и выбирать инструмент под задачу.

Не понял стебя да? Что - не подошел орм?

>Простите.

Прощаю. Но все же сходите на iBatis и обясните разработчикам там что они неправы и их инструмент ORM. Они наверное по глупости своей не знают об этом.

а по поводу импенданса - собственно ОРМы и пытаются его преодолевать. вот насколько успешно и красиво - вопрос другой. но важно то что _пытаются_. это плохо?

>>А потом отгребают кучу побочных еффектов.

>Именно.

ну так я вроде бы сказал какие действия необходимы для предотвращения побочных еффектов? или вы думаете что без ОРМов Вам не придется делать таких же (если не худших и бОльших) действий? суть в том что доступ к данным и их (данных) дальнейшее использование - разные вещи, их нужно разделять. что вообще означает понятие ДАО? если доступ к данным будет происходить за пределами уровня ДАО - то в чем тогда вообще смысл существования такого понятия как "объекты доступа к данным"? концепция ДАО именно для того и существует чтобы ограничить и локализовать _все_ действия с базой данных на _одном_ четко определенном уровне имплементации, и _гарантировать_ что _за_ пределами этого уровня _никаких_ операций с базой данных производиться не будет. как иначе эту гарантию можно дать если не _разрывом_ связи между базой данных и объектами которые представляют данные из базы по выходе из уровня ДАО? но разрыв связи при пересечении границы между ДАО и другим (высшим) уровнем совсем не означает что внутри ДАО не должно быть ОРМа. естественно его там _может_ не быть - но никто и не запрещает ему там быть. это уже вопрос реализации. есть у вас время лишнее - пишите свой ОРМ (в итоге). иногда это бывает необходимо.

Разыскивается автор вот этого поста:

> а по поводу "вредности" ОРМов хочу добавить что даже если ОРМ и "зло" то "зло " необходимое... просто не нужно использовать его там (точнее не там) и так (точнее не так) где он вреден. Задача ОРМа весьма узкая - дата-лейер, персистенция. всё. всё остальное задача других уровней и паттернов. смешивать и передавать напрямую непосредственно модель из одного уровня в другой - ССЗБ. классический пример я уже приводил: ORM vs MVC. Как правило не долго думая в качестве модели (ну уж в составе модели так точно) используют непосредственно замапленные объекты. А потом отгребают кучу побочных еффектов. А откуда позвольте спросить следует что модель дата лейера должна быть непосредственно адекватна модели представления? Как правило между моделями дата лейера и презентейшина есть очень существенные различия. Настолько существенные что просто нет особого смысла использовать непосредственно объекты из дата лейера. А вот что имеет смысл - провести трансформацию данных из объектов дата лейера в модель представления путем __необходимого_копирования_ (!!!). И всё. Дальше можете делать с новой моделью всё что вам будет угодно ни о чем не беспокоясь. Побочных еффектов не будет. И загрузите вы из базы ровно то что вам будет нужно не больше и не меньше. Хоть по сети передавайте, хоть обрезайте текст, хоть в формочках редактируйте. Кстати о формочках - еще одна причина разделения моделей дата лейера и презентейшина заключается в том что в процессе ввода данных в формочки и последующей валидации этого ввода необходимо сохранять отображение даже принципиально неверных данных (например не того типа - буквы вместо цифр например) - иначе пользователь просто не поймет что он сделал не правильно. естественно выделить красным там цветом эти буквы и сказать ему - введите пожалуйста цифры. и вот скажите мне - как это сделать если пытаться сохранять форму непосрественно в модель данных ОРМа? уверен что никак. а дело все в том что и нет в этом никакой необходимости. ну покажите мне где нибудь пример из спринга где так делается? везде форма имеет _свою_модель. которая _после_ валидации трансформируется копированием в другую уже модель которая и передается в дао.

Отозвался не тот аноним. Пишите на rodion (aт) generation-p.com

Похоже, это тот же:

> ну так я вроде бы сказал какие действия необходимы для предотвращения побочных еффектов? или вы думаете что без ОРМов Вам не придется делать таких же (если не худших и бОльших) действий? суть в том что доступ к данным и их (данных) дальнейшее использование - разные вещи, их нужно разделять. что вообще означает понятие ДАО? если доступ к данным будет происходить за пределами уровня ДАО - то в чем тогда вообще смысл существования такого понятия как "объекты доступа к данным"? концепция ДАО именно для того и существует чтобы ограничить и локализовать _все_ действия с базой данных на _одном_ четко определенном уровне имплементации, и _гарантировать_ что _за_ пределами этого уровня _никаких_ операций с базой данных производиться не будет. как иначе эту гарантию можно дать если не _разрывом_ связи между базой данных и объектами которые представляют данные из базы по выходе из уровня ДАО? но разрыв связи при пересечении границы между ДАО и другим (высшим) уровнем совсем не означает что внутри ДАО не должно быть ОРМа. естественно его там _может_ не быть - но никто и не запрещает ему там быть. это уже вопрос реализации. есть у вас время лишнее - пишите свой ОРМ (в итоге). иногда это бывает необходимо.

Пишите на rodion (aт) generation-p.com

>Так в чем проблема - делайте именно так :) кто мешает то?

Госпаде - сколько лишних слов. Релакс. А ведь как все просто. Берем любейший пример из любейшей книжки по ежб. Что там есть? Пользовательские счета - модель. Какая нить ЖСПшина - просмотр. А бизнес методы там какие? withraw? balance? transfer? Вот подумайте почему они называются _бизнес_ методы.

И перечитайте паттерн MVC. Ваша точка зрения навеяна "хачу быть MVC"-веб фреймворками и "MVC в нас помещается так" описанием. http://java.sun.com/blueprints/patterns/MVC-detailed.html. Ключевая ошибка - контролер ничего для View не готовит. Model - domain data, View - конкретное представление domain data, controller - реагирует на события изменяя модель. Он ничего для View _не готовит_. Максимум - он может выбрать конкретный view из возможных. Как пример грамотной реализации MVC - смотрите свинг. Основное назначение MVC - развязывание данных. Если у вас контроллер что-то готовит для view - это прямо противоположное действие самому смыслу существования MVC. Это значит что он знает о том как view собрался отображать модель. А это именно то что этот паттерн стремится побороть.

> естественно не обязательно, но почему бы и нет?

Потому что "почему бы и да" - длолжно быть обосновано. Польза есть?

>и для чего еще нужны объектные деревья как не для абстракции от деталей имплементации сложных структур данных?

Как минимум тем что там нету никакой абстракции (в случае ORM). Посмотрите на анонимные структуры С#, и их подход к тому какие деревья должен возвращать SQL.

>и если не заканчивается то разве и не начинается??

Я про то что не все где есть обекты - ОО программа. Слышали выражение "это не С++, а С с классами"? Тут ровно то же самое. Объектность - не характеристика орма. Это просто технология с классами.

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

Обоснуйте ненужность самолета для прелета на растояние 10 кварталов из дома до работы. Ведь удобно, стюардессы, завтрак опять же - командир корабля желает доброго утра - клондайк просто.

Вы лучше обоснуйте ее неоходимость. Что даст ORM в оставленной задаче кроме ненужного усложнения системы?

>не на объекты?

А ООА/D/P это по вашему объектики? Я прямо поражаюсь. ДЕмонстрируйте мне где там сокрытие реализации, месседж пассинг, инкапсуляция, полиморфное поведение, где вообще какое либо поведение? Покажите мне где уменьшается сложность софта через предоставление узких интерфейсов, сокрытие деталей реализации, покажите code reuse в продукте, который делает ORM и прочие хрени которыми характеризуется и для чего вообще придуман ОО?

>что конкретно нарушается в ООД в случае ОРМов?

Оно там _отсутствует_. То есть - вообще.

>Ну есть некоторый "когнитивный диссонанс".

Это не когнитивный диссонанс а принципиальные отличия. Или для повашему подход к интерфесам принятый в RDB как "предоставление данных" в отличии от OO где интерфейс это "предоставление поведения" это когнитивный диссонанс? И дальше по списку.

>"Объектные характеристики" имеет даже тупой JDBC.

JDBC совсем не тупой. Стандарт JDBC очень грамотно с точки зрения OOA/D спроектированная библиотека. Она обладает всеми характеристиками присущими OO библиотеке.

А дерево объектов, которое порождает ORM такими характеристиками не обладает.

>Дурь это, а не ключ

Серьезно? И чем он дурь?

>а по поводу импенданса - собственно ОРМы и пытаются его преодолевать.

На сегодняшний день - не очень. Этот импенданс - это физическая и идеологическая разница в подходах. Пока ормы ограничиваются перетаскиванием реляцинных данных в dummy structure которая не обладаех характеристиками объектной библиотеки, и наоборот обладает целым набором анти-объектных характеристик.

>Это не когнитивный диссонанс а принципиальные отличия. Или для повашему подход к интерфесам принятый в RDB как "предоставление данных" в отличии от OO где интерфейс это "предоставление поведения" это когнитивный диссонанс? И дальше по списку.

Спешу тебя обрадовать, в RDB НЕТ понятия "интерфейсов". Вообще. RDB (классические Коддовские) работают с таблицами кортежей. Все, точка.

В качестве _представления_ реляционных данных элементарно можно использовать классические графы объектов. Обратное тоже верно, но с оговорками - наследование на RDB ложится очень плохо.

>А дерево объектов, которое порождает ORM такими характеристиками не обладает.

Т.е. граф объектов, не является объектным? You've made my day...

>есть у вас время лишнее - пишите свой ОРМ (в итоге)

Я совсем не против ормов - я сам ими пользуюсь (при чем настоящими, а не sqlmap). Я защищаю только 2 тезиса: 1) данные из орма - это репрезентация базы, они должны обладать всем констрейнтами, которыми обладает база, из этого автоматически проистекает, что предлагамая валидация прямо в ORM-объектах - невозможна. 2) ORMы не везде применимы. Существуют задачи где внедрение ORM приведет к появлению дополнительных ограничений, которые придется преодолевать (прямой аналог это как, если бы все объекты в программе были enterprise beans абы кластеризовалось и все такое - никому в голову же не приходит такой бред? ТАк почему аппликабельность ORM вообще не анализируется?), либо к усложнению программы (как пример я привел задачу которая ограничена функциями вывода на экран и редактирования строк из базы). В любом RAD инструменте такой интерфейс клепается за минуты без всяких ормов. Но нет - мыж умные энтерпрайз архитекторы - мы себе геморой придумаем и будем с ним разираться месяцами.

А в самом ORM ничего плохого нет. Это просто очередной "не silver bullet" который не стоит пихать куда попало только заслышав слово "данные".

Блин, опять не тот адрес!

rodney@, не rodion@.

Моя позиция такова:

Каждый слой в приложении пишется исходя из того, что нужно его
"клиентам" - тем, кто юзает этот слой + , естественно, ограничения
имплементации. При этом, по возможности, middle-tier (aka Module
Facade) должен спрятать за собой детали имплементации.

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

Допустим, я дал доступ фронтенду к ДАО (или к ДАО-объектам, за счёт
отсутствия или очень-очень тонкого мидл-тира). Имеем: вызовы к базе
напрямую из фронтенда, типа:

List<HotelDescriptor> hotelDescriptors = 
hotelDao.getHotelsByCriteria(hotelSearchCriteria);
for (HotelDescriptor hotelDescriptor: hotelDescriptors)
{
 for (HotelRoomType roomType: hotelDescriptor.getRoomTypes())
 {
  // делаем что-нибудь с roomType'om.
...
 }
}

1. Отгребаем по полной, если hotelDescriptor сохранился в сессии (или
в JSF t:saveState), т.к. к RoomTypes у нас доступа уже не будет.
2. Самое главное: если завтра вместо базы у нас будет web-servis (а в
туризме это случается сплошь и рядом), то мы можем получить
концептуальную проблему, т.к. выборка типов комнат может делаться
отдельным web-service-call'ом.

Решение состоит в том, чтобы за пределы ModuleFacade выпустить как
можно меньше имплицитной инфы по связке объектов друг с другом. Т.е.,
вместо hotelDescriptor.getRoomTypes() юзаем:

hotelServiceFacade.getRoomTypesFor(hotelDescriptor).

Это позволит нам до поры-до времени баловаться с hibernate, (или с
JDBC), но не исключает и имплементации бэкенда в виде web-service.

Кроме того:
O/R ДАО позволяет перенести модель БД в объекты. Проблема же в том, что в
каждом конкретном случае, фронт-энду не нужен весь слепок базы в виде
объектов. Ему нужен определённый срез данных. Причём, разным частям
фронт-энда нужны разные срезы с одних и тех же данных. Введение
мидл-тира позволяет приготовить такие срезы, не завязывая фронт-энд на 
технологию, которая используется для хранения и доставания данных.

Ну, и, наконец, между фронт-эндом и мидл-тиром вообще будут
существовать сущности, которых в базе нет. Например: в базе есть инфа
по доступным комнатам и правила формирования цены за каждый день.
Когда фронт-энд запрашивает у мидл-тира предложения на 2-х взрослых, с 
1.1.2008 по 7.1.2008 он ожидает получить набор возможных offer'ов,
каждый из которых будет содержать уже просчитаную стоимость на эти
даты. Такого объекта в базе вообще нет.

Мой принцип при проектировании: сделать интерфейс мидл-тира:
1. Максимально удобным для фронт-энда.
2. Минимально зависимым от БД (ili chto u nas tam).


Rodion (aka rodney@)

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

>RDB (классические Коддовские) работают с таблицами кортежей. Все, точка.

Эти таблицы кортейжей это интерфейс к данным. Восклицательный знак.

>Т.е. граф объектов, не является объектным?

Слово "объектов" может в этом выражении может быть заменено на "структур", "кортежей", "наборов", "данных".

Так что да - впомянутый тобой граф - не объектен с точки зрения ООА/Д.

>Моя позиция такова:

Во - абсолютно грамотная позиция основаная на бизнес требованиях, анализе и функциональных абстракциях, пример грамотного проектирования.

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

>Каждый слой в приложении пишется исходя из того, что нужно его
"клиентам" - тем, кто юзает этот слой + , естественно, ограничения
имплементации. При этом, по возможности, middle-tier (aka Module
Facade) должен спрятать за собой детали имплементации....

уважаемый, Родни, я _тот_ аноним и я ответил Вам по имейлу (уже в который раз). в письме я сказал что выскажу свое мнение по Вашим мыслям немного позже (думаю что уже не сегодня). ок?

Zhal'.

Mne nuzhno ubegat' - u menja samolet cherez 2.5 chasa.

Esli budet zhelanie - moj ICQ 1682160.

Vy daleko ot Minska obitaete?

Rodion

>Во - абсолютно грамотная позиция

Только одно замечание - требования клиентов должны быть не конкретными а обобщенными, иначе при мелких модификациях надо будети цеплять слишком много кода. Например если надо получить список свободных одноместных номеров, а номера бывают одно, 2х и 3х, то не надо делать метод getFreeSingleRooms(), более разумно сделать getFreeRooms(type). Это за те же затраченные усили порождает в 3 раза большую функциональность с более высоким уровнем абстракции.

> Только одно замечание - требования клиентов должны быть не конкретными а обобщенными, иначе при мелких модификациях надо будети цеплять слишком много кода. Например если надо получить список свободных одноместных номеров, а номера бывают одно, 2х и 3х, то не надо делать метод getFreeSingleRooms(), более разумно сделать getFreeRooms(type). Это за те же затраченные усили порождает в 3 раза большую функциональность с более высоким уровнем абстракции.

Абсолютно верно. Более того, именно поэтому я писал:

hotelServiceFacade.getHotels(hotelCriteria)

а не

hotelServiceFacade.getOneStarHotels()

и даже не

hotelServiceFacade.getHotelsByCategory(1)

Поскольку hotelCriteria - это POJO, нет никакой проблемы объэвить его в АПИ enterprise-module'я и использовать как во фронтэнде, так и вплоть до бэк-энда.

В общем-то, удобство hibernate Criteria, это один из решающих факторов, почему в нашем проекте hibernate ещё не "фтопке", т.к. имплементация ДАО заключается лишь в мэпинге АПИ-шного ПОДЖО-шного criteria в hibernate'овские Criteria. Если бы не это, то вообще, более предпочтительным механизмом доступа вижу SpringJDBC.

Но это абсолютно не повод отдавать hibernate'овские объекты во фронтенд. Всё, что пересекает границу ModuleFacade <-> Frontend - незамысловатые (без всяких прокси, спрятанных ссылок на сессии и т.п.) POJO. Только так!

Rodion

P.S. @Паша: если ты это читаешь, передай админу большой привет от Родиона. И большое спасибо за безукоризненно работающий мэйл.

Vsjo: ushjol.