Spring Framework 2.5

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

я Вам и на ICQ ответил уже..)) но Вы и там видимо не доступны. собственно там я тоже сказал лишь то что сейчас толком подумать над Вашими мыслями и ответить чем то Вам потенциально полезным к сожаления сегодня уже времени нет. как только будет время и что то разумное в голову придёт - попробую вам по почте написать. или хотя бы тут запостить...

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

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

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

В практических базах - есть SQL. От него на прикладной уровень идут динамически типизированые кортежи данных.

ORM позволяет от этой нетипизированости избавиться. Только и всего.

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

Мне, честно говоря, пофиг на некую абстрактную "объектность". ORM позволяют мне удобно работать _с_ _данными_. А то что их не считаешь полноценными объектами - твои проблемы.

продолжая тему "для Родиона от _того_ анонима":

мне лично кажется что вы идете (в высказанных размышлениях) не по совсем верному пути. развивая идею абстрактной модели я бы посоветовал вам обратить внимание на паттерн ValueObjects http://en.wikipedia.org/wiki/Value_Objects

Один из вариантов применения этого паттерна заключается в том что для _каждого_ интерфейса domain object'а (как минимум для тех которые пересекают границы подсистем) должно быть как минимум _две_ имплементации. Первая (или вторая не важно) - зависящая от имплементации (то есть например замапленая ОРМом). Вторая - чистая, "простая", я бы даже сказал "тупая" - простые бины, не отягощенные никаким лишним и зависящим от имплементации интеллектом - они то (именно эти бины) и называются ValueObjects. И между уровнями передаются именно эти ValueObjects. Их задача быть простыми _значениями_. И именно эту задачу они и должны выполнять. А уже допустим дата лейер берет свой инпут из какого нибудь ValueObject'а и копирует в ORM-mapped близнеца этой сущности. Обратно - после получения из ОРМа сущности она копируется в его тупого брата-близнеца (значение, ValueObject) и отдается в другой уровень уже именно этот ValueObject.

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

Правильно _данных_.

>ORM позволяют мне удобно работать _с_ _данными_.

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

>на паттерн ValueObjects

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

продолжая тему "для Родиона от _того_ анонима":

естественно в такой иплементации (через VO) опять встает проблема lazy-loading. как бы я разрешил эту проблему я напишу Вам в письме позже.

>Ничего хорошего в этом паттерне нет. Его мотивация - побороть архитектурные особенности - в частности орма, ремотинга.

цель этого паттерна - абстракция. что в этом плохого?

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

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

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

ЕЖБ для вас предел ООД? Вот как раз ЕЖБ решает скорее _технологические_ чем архитектурные проблемы. Если сомневаетесь спросите себя - зачем нам ЕЖБ? Что такого особенного они делают?

>И перечитайте паттерн MVC

читаю http://en.wikipedia.org/wiki/Model-view-controller

The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller.

В чем я _опять_ не прав по Вашему мнению?

>ДЕмонстрируйте мне где там сокрытие реализации, месседж пассинг, инкапсуляция, полиморфное поведение, где вообще какое либо поведение?

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

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

здесь нет ненужности. здесь есть скорее недоступность - нет такого самолета который мог бы пролететь именно от дома до работы. если бы был - почему нет? как минимум прецеденты есть - некоторые особо продвинутые личности летают на работу в вертолетах _изза_пробок_.

>цель этого паттерна - абстракция. что в этом плохого?

Цель этого паттерна - не тащить чквозь лееры то что не тащится чисто технически. Второе его название Data Transfer Object.

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

Расказываю на пальцах: метод balance должен возвращать цифру, а не запись из базы данных. Метод withdraw должен принимать цифру, а не

account.setValue(account.getValue() - 50);

facade.store(account);

Вот так тут обходится без VO:

facade.withdraw(50);

>ЕЖБ для вас предел ООД?

Я просто привел широкораспространенный пример из широкораспространенных кних которые в основном и ввели в обиход понятие бизнес-логика. Само ежб тут перпендикулярно. По сути возражения есть?

>В чем я _опять_ не прав по Вашему мнению?

В том что контролер готовит данные для вьев. Не готовит. Если контролер готовит данные для мьев - это значит что он знает структуру данных которые необходимы вьев а следовательно имеем жесткий каплинг, сол сменой вьев надо меть контролер. Вьев сам должен брать данные из модели. Контроллер отвечает лишь за реакции на события и меняет модель. Посмотрите картинку на сане - там нарисовано кто за чем и куда лазит.

>в рамках джавовской реализации в ОРМе есть _вся_возможная_ ООП парадигма.

Чего-чего-чего? При чем тут джава? В джаве все есть. Этого нет не водном обекте порождаемом ОРМом.

>Вы считаете что в ОРМе нет полиморфного поведения? очитайте документацию по используемому Вами ОРМу.

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

>здесь есть скорее недоступность - нет такого самолета который мог бы пролететь именно от дома до работы.

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

> Расказываю на пальцах: метод balance должен возвращать цифру, а не запись из базы данных.

Причем тут запись из базы данных? Объекты из методов ДАО передаваться могут или нет?

> По сути возражения есть?

По сути _чего_ должны быть возражения? Вы привели ЕЖБ как пример хорошего ООД, я усомнился в том что у ЕЖБ хороший ООД. Вот это помоему и есть возражение по сути. Это Вы скорее должны мне объяснить зачем нужен ЕЖБ в случае не нужности ОРМа.

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

Контроллер не готовит данные для вьёв? А кто ж тогда их готовит? И что такое модель как не данные для вьев? Контроллер _обязан_ знать структуру данных для вьев. Иначе это уже не МВС никакой. Все что во вью может меняться - представление модели (рендеринг). Без изменения контроллера никаких изменений в модели быть не может. Естественно из модели данные вью берет сам. Но модель то кто определяет? Не контроллер? Помоему мы о чем то разном одинаковыми словами говорим....

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

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

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

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

Секундочку. О каких порождаемых ормом объектах идет речь? Разве орм порождает не указанные вами же замапленные объекты? Вы хотите сказать что орм мешает вам чем нибудь применять в модельных объектах полиморфизм? Чем же конкретно орм мешает полиморфизму в замапленных объектах?

Насчет инкапсуляции я даже не знаю что сказать - покажите где её нет, может быть тогда мне будет легче понять чего именно вам не хватает.

Относительно интерфейсов - тоже самое что и про полиморфизм: вы сами определяете всю модель с которой работает ОРМ. что мешает вам взаимодействовать с вашей моделью через интерфейсы?

ссылки в частности вот

http://www.hibernate.org/hib_docs/v3/reference/en/html/inheritance.html#inher...
http://www.hibernate.org/hib_docs/v3/reference/en/html/inheritance.html#inher...

>Причем тут запись из базы данных? Объекты из методов ДАО передаваться могут или нет?

Вот и вернет ORM объект Account. Дальше что? set get minus store ?

>Вот и вернет ORM объект Account. Дальше что? set get minus store ?

да, а в чем проблема? это разве не бизнес-логика? вы собираетесь иплементить бизнес-логику прямо в ДАО? каким же образом? просветите.

>Вы привели ЕЖБ как пример хорошего ООД

Я привел примеркоторый употребляется в книжках по ЕЖБ чтобы объяснить что такое бизнес логика. Вот в чем суть.

>Контроллер не готовит данные для вьёв? А кто ж тогда их готовит?

Никто не готовит. Конкретный вьев сам извлекает данные которые ему нужны из модели и показыввает их как хочет. Прочитайте ссылку которую я дал - там же все написано с картинками.

>Контроллер _обязан_ знать структуру данных для вьев. Иначе это уже не МВС никакой.

http://java.sun.com/blueprints/patterns/images/mvc-structure-generic.gif

Controller - The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.

Где тут написано что он готовит данные для view?

View -The view renders the contents of a model. It accesses enterprise data _through the model_ and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data.

Сантехники врут? http://java.sun.com/blueprints/patterns/MVC-detailed.html

>Выше написано - тебе придется таскать его по всем связанным таблицам и вручную поддерживать зависимости.

Потому что он не синтетический?

>Сантехники врут?

а что не могут сантехники врать? если вы считаете что МВСом может быть только то что названо этим словом в ЕЖБ то боюсь вы несколько заблуждаетесь. причем это именно так причина по которой я ЕЖБ не считаю хорошим дизайном. если вам интересно что я считаю хорошим дизайном и хорошим МВС - почитайте как это сделано в спринге. который мы кстати тут вроде бы и обсуждаем

по сановскому блюпринту согласно этому

Model - The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model.

бизнес-логика должна быть именно в модели и нигде иначе. вы считаете это хорошим дизайном?

читаем дальше

View -The view renders the contents of a model. __It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data__.

вы меня извине но это уже полное уродство.

я могу даже пояснить почему уродство.

если бизнес-логика это часть модели, а вью напрямую вызывает модель, то что мешает вью напрямую работать с бизнес-логикой? зачем тогда контроллер? где гарантии что мы не получим какие нибудь побочные еффекты когда вью активирует какуюнибудь бизнес-логику из модели? у нас что - должно быть _две_ модели - одна для контроллера а другая для вью? иначе как мы можем гарантировать недоступность активации бизнес логики из вью? или такие гарантии не нужны?

> Чем же конкретно орм мешает полиморфизму в замапленных объектах?

Полиморфное поведение будет какое? Что там вообще будет полиморфного?

>Насчет инкапсуляции я даже не знаю что сказать - покажите где её нет

ее нигде нет. Реализация и внутренняя структура для орма не только открыта, она с ним синхронизирована. Он ковыряется в объектах как хочет.

>что мешает вам взаимодействовать с вашей моделью через интерфейсы?

Ничего. Через те самые интерфейсы я могу взаимодействовать хоть с объектами, хоть с xmlями, хоть с JDBC, хоть бинарным дампом сетевого трафика. Сама модель - необъектна. Некорректно говорить что ОРМ дает объектность - в самой модели порождаемой ормом ничего объектного нет.

>ссылки в частности вот

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

>да, а в чем проблема? это разве не бизнес-логика?

Ага. Только имплементирована не в ивде бизнесметода, а неотходя от кассы. В таком виде она была и до существования трехзвенной архитектуры.

> вы собираетесь иплементить бизнес-логику прямо в ДАО? каким же образом? просветите.

http://java.sun.com/blueprints/patterns/SessionFacade.html

>если вы считаете что МВСом может быть только то что названо этим словом в ЕЖБ то боюсь вы несколько заблуждаетесь

Я боюсь что эта статя к EJB никакого отношщения не имеет.

>если вам интересно что я считаю хорошим дизайном и хорошим МВС - почитайте как это сделано в спринге

Спринг делает ту же ошибку что и многие вебфреймфорки - он так хочет быть MVC что придумывает где он MVC. Зачем спрашивается? MVC не пуп земли. Ошибка распространенная - про которую я и указывал выше. Если модель формируется контроллером и передается для конкретного вьев значит вьев связан (tight coupled) с контроллером, и это обозначает что для написания другого вьев нужен будет другой контроллер или любые желания мьева менять данные которые уму нужны из модели тут же затрагивает контроллер. В случае спринга MVC и есть тот самый буззворд который обсуждали выше. Где за желанием названия потеряли суть - зачем это нужно. Лишь бы ярлык себе налепить.

Хороший MVC - Swing.

>бизнес-логика должна быть именно в модели и нигде иначе. вы считаете это хорошим дизайном?

В не поняли что такое модель. Модель - это _не_ данные. Например в случае какогото устройства модель это набор методов по работе с этим устройством. Моделью может выступать библиотека или набор методов. Вылезите уже из этого ограниченого мира вебфреймворков, которые ползают в реляционные базы данных.

>вы меня извине но это уже полное уродство.

Это MVC. И решает оно именно поставленную задачу. Оно отвязывает различных клиентов и интерфейсы от манипуляции данными создавая дополнительный слой контролер. Таким образом мы релизуем в модели - именно бизнесмодель данных или процессов которые происходят в нашем домене. Вьев отвечат исключительно за отображение состояния модели. А всякие фидбеки шлет контролеру. Тот колбасит модель как мождет. В результати такого дизайна имеем независимость всех трехсоставляющих - можно делать другие вьевы обращаясь к одним и тем же контроллерам, и моели. ДАвно писали например принципиально различную административную и пользовательскую часть сайта заменив _исключительно_ жспшки, и оставив все те же самые акшены и данные?

>иначе как мы можем гарантировать недоступность активации бизнес логики из вью?

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

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

С каких пор? Источник, ссылку, фрагмент кода в студию.

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

Кому нужны и кто так говорит? Почему они им нужны? Не потому ли, что они
не знают про акселератор?

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

Ну, дурдом в цикле! Сравнивали опять без акселератора? ;)

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

>ДАвно писали например принципиально различную административную и пользовательскую часть сайта заменив _исключительно_ жспшки, и оставив все те же самые акшены и данные?

и вы считаете что это хорошо?? какой ужас....

>Это MVC.

да вы почитайте что ли что такое классический MVC который был в смоллтоке

http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html

Communication Within The MVC Triad

The model, the view and the controller involved in the MVC triad must communicate with each other if an application is to manage a coherent interaction with the user. Communication between a view and its associated controller is straightforward because View and Controller are specifically designed to work together. Models, on the other hand, communicate in a more subtle manner.

The Passive Model

In the simplest case, it is not necessary for a model to make any provision whatever for participation in an MVC triad.

>Пока ормы ограничиваются перетаскиванием реляцинных данных в dummy structure которая не обладаех характеристиками объектной библиотеки, и наоборот обладает целым набором анти-объектных характеристик

Ну жаль тебя, если У ТЕБЯ ормы ограничиваются перетаскиванием реляционных данных в dummy structure которая не обладаех характеристиками объектной библиотеки, и наоборот обладает целым набором анти-объектных характеристик. У всех остальных ОРМы служат для перзистенса объектов уже готовой Domain Model, обладающих вполне определенным поведением а не dummy, в тупую базу данных, которую ДАЖЕ не проектируют заранее. А АБД нужен только для настройки индексов там и т.п. Конечно бывают случаи когда пляшут от унаследованной структуры БД и строят переходную объектную модель на ее основе, которую постепенно переделывают к правильной Domain модели и соответственно уже данные сохраняют в БД отражающую ПРАВИЛЬНУЮ структуру предметной модели

>В любом RAD инструменте такой интерфейс клепается за минуты без всяких ормов. Но нет - мыж умные энтерпрайз архитекторы - мы себе геморой придумаем и будем с ним разираться месяцами.

Чё? Это типа написать обработчики выхода курсора из строки таблицы и валидации этой строки прямо в коде .DPM? Или .DFM как там его бишь? Спасибо, наелись, иби.есь сами со своей Delphi XP 2007 "Enterprise" RAD Edition

>Ага. Только имплементирована не в ивде бизнесметода, а неотходя от кассы.

кто вам это сказал? вы считаете что бизнес-методы должны быть непосредственно в ДАО? а что тогда делать если мы будем переносить наше приложение не другую базу? на другую модель данных? например на не реляционные источники? разве бизнес-логика не должна быть абстрагированна от физического представления данных уровня хранения?

>http://java.sun.com/blueprints/patterns/SessionFacade.html

а каким образом этот фасад всплывает в жсп? кстати отрицаемые вами Transfer Objects там почему то рекомендованы к употреблению....

и где там кстати сказано (по ссылке) что фасад прямо из вью нужно вызывать?

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

>Полиморфное поведение будет какое? Что там вообще будет полиморфного?

такое какое вы определите и реализуете. любое какое вам угодно.

>ее нигде нет. Реализация и внутренняя структура для орма не только открыта, она с ним синхронизирована. Он ковыряется в объектах как хочет.

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

>Ничего. Через те самые интерфейсы я могу взаимодействовать хоть с объектами, хоть с xmlями, хоть с JDBC, хоть бинарным дампом сетевого трафика. Сама модель - необъектна. Некорректно говорить что ОРМ дает объектность - в самой модели порождаемой ормом ничего объектного нет.

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

>Ну - о чем я и говорю. Эти объектны полиморфны настолько же насколько можно назвать полимофрными таблицы в базе данных.

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

>> Нужны акселераторы, делающие JIT-компиляцию в нативный код. >Кому нужны и кто так говорит? Почему они им нужны? Не потому ли, что они не знают про акселератор?

Нужны любому, кто понимает разницу между интерпретатором и JIT-компилятором.

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

Нет. Сравнивали на реальных приложениях, типа phpBB.

>> Чем же конкретно орм мешает полиморфизму в замапленных объектах? >Полиморфное поведение будет какое? Что там вообще будет полиморфного?

Как запрограммируешь - так и будет. Какие проблемы-то? Добавляешь метод, в наследнике переопределяешь. Только вот смысла в полиморфных объектах в RDB очень мало - нет нормальных способов выражать наследование.

>>От него на прикладной уровень идут динамически типизированые кортежи данных. >Правильно _данных_.

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

>>ORM позволяют мне удобно работать _с_ _данными_. >Я не понимаю - против чего ты споришь? В этом то и суть - ОО говорит не о данных, а о _поведении_.

ОО вообще ничерта ни о чем не говорит. Основной принцип ОО - это LSP (Liskov Substitution Principle). Объекты ORM ему вполне удовлетворяют.

>И потому аргумент "объектности" не применим к орму - это просто граф объектов представляющий данные.

Дальше-то что? Естественно, это "просто" граф _полиморфных_ _объектов_. Можно прямо в него поведение наляпать - никто не мешает это сдедать. И оно даже будет все работать.

Только хорошим тоном считается оставлять объекты DAO _чистыми_ - это упрощает _разделение_ поведения и данных. Хотя бы просто из-за того, что объем бизнес-кода поведения обычно в десятки раз больше объема DAO.

>Перенос положительных аспектов, которые проистекают из использовании ОО в разработке систем на ормы не обоснован. Мне тоже пофиг на абстрактную объектность. Просто предидущий оратор привел ее как положительную фишку орма. Это не так.

Я плохо понимаю что такое "абстрактная объектность". ORM дает мне реальные преимущества - упрощение работы с данными, представляя записи в базе в виде связаной структуры "объектов" (ну называйте их "структурами", что ли).

>Только вот смысла в полиморфных объектах в RDB очень мало - нет нормальных способов выражать наследование.

Есть. почитайте ссылки приведенные выше

>>Ну, дурдом в цикле! Сравнивали опять без акселератора? ;)

>Нет. Сравнивали на реальных приложениях, типа phpBB.

Очнись. Ты даже приблизительно не понял то, что тебе сказали.

>>Только вот смысла в полиморфных объектах в RDB очень мало - нет нормальных способов выражать наследование. >Есть. почитайте ссылки приведенные выше

Я прекрасно знаю как МОЖНО выразить наследование в RDB. Но все способы имеют разные недостатки. Join-таблицы увеличивают время запроса (лишние join'ы), дискриминаторы требуют вызывают хранение лишних столбцов, таблица-на-класс - вообще неудобна в полиморфных запросах.

Нет, эти стратегии МОЖНО использовать, я не спорю. Но они некрасивы.

>>>Ну, дурдом в цикле! Сравнивали опять без акселератора? ;) >>Нет. Сравнивали на реальных приложениях, типа phpBB. >Очнись. Ты даже приблизительно не понял то, что тебе сказали.

А, протормозил на слове "в цикле". Ну ладно, посмотрел eAccelerator: http://www.ipersec.com/index.php/2006/05/30/benchmarking-php-accelerators/

Ускорение примерно в 3-5 раз. Не фонтан - чистая Java на бенчмарке без обращения к БД (подсчет сотни md5-сумм и работа со строками) работала у меня в _двести_ раз быстрее чистого PHP.

Сделайте Django-версию моего изначального теста, мне ее тоже посмотреть хочется. Или боитесь?

>>Ничего хорошего в этом паттерне нет. Его мотивация - побороть архитектурные особенности - в частности орма, ремотинга.

>цель этого паттерна - абстракция. что в этом плохого?

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

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

Ну, во-первых, не дата лэйера, а ModuleFacade. А во-вторых, почему-это фронт-энд не может подёргать методы ModuleFacade? Ведь фасад для фронт-энда и пишется.

У меня сейчас идут два проекта, в которых я пробую этот способ доступа к данным. Один - поменьше, и тут я попробую обкатать этот метод (я тут и архитект и девелопер). В проекте побольше можно будет ещё что-нибудь поменять, если метод себя не оправдает (тут я почти не девелоплю).

VO (или DTO) - довольно неприятная вещь. Я столкнулся с ним на предыдущем проекте, где он, действительно, использовался для борьбы с кривым ремотингом (архитектуру делал не я, и иногда мне кажется, что этот кривой ремотинг, может, специально воткнули в архитектуру, чтобы гарантировано отцепить фронт-энд от бэк-энда).

Хотя, если отказаться от ДТО насовсем, то возникает ряд проблем с вью: мы используем JSF в обоих проектах. И в JSF есть EL, который предоставляет возможность лазить по свойствам объектов. Вот тут то и возникает проблема: как воткнуть вызов к ModuleFacade, когда в EL написано "#{hotel.getRoomTypes}".

Или как по-другому решить эту проблему?

>поэтому жспшка не сможет нарушить контракт.

Та шо вы говорните:

Bean factories and application contexts are often associated with a scope defined by an application server or web container, such as:

* A Servlet context. In the Spring MVC framework, an application context is defined for each web application containing common objects. Spring provides the ability to instantiate such a context through a listener or Servlet without dependence on the Spring MVC framework, so it can also be used in Struts, WebWork or other web frameworks. * A Servlet: Each controller Servlet in the Spring MVC framework has its own application context, derived from the root (application-wide) application context. It's also easy to accomplish this with Struts or another MVC framework.

These hooks provided by the Java EE specifications generally avoid the need to use a Singleton to bootstrap a bean factory.

However, Spring can be used standalone, and it's trivial to instantiate a BeanFactory programmatically. For example, we could create the bean factory and get a reference to the business object defined above in the following two statements...

Вы шо шутите чтоли? Если бы спринг что-то такое гдето запрещал на таком уровне - он бы и нахре никому нужен не был как закрытая среда. Уж не говоря о том что такое даже теоретически трудно представить.

>и вы считаете что это хорошо?? какой ужас....

Это прекрасно! А что вас не затруднит обосновать ужас?

>да вы почитайте что ли что такое классический MVC который был в смоллтоке

Читаю: The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller)

Это полностью совпадает с статьей на сане.

the model...responds to requests.... (usually from the view)...responds to instructions...(usually from the controller).

Читайте свои ссылки - там же все написано.

>У всех остальных ОРМы служат для перзистенса объектов уже готовой Domain Model, обладающих вполне определенным поведением а не dummy

Серьезно? Пример можно? "Правильной домайн модели".

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

Это вам бабушка на ушко нашептала да? Посмотрите как это сделано в .NET Web Forms, Adobe Flex, JSF. А не рассказывайте сказки. Сгернерировать диалог редактирования для базы данных очень легко зная описание описание данных. Не умеете - раскладывайте дальше контролы руками, выводите циклами в жспшках строчки, и занимайтесь прочей работой которую человек руками делать не должен.

>вы считаете что бизнес-методы должны быть непосредственно в ДАО?

А вы что DAO в наружу высталяете?

>а что тогда делать если мы будем переносить наше приложение не другую базу?

А где тут с вязь?

>на другую модель данных?

О - это я вас хочу спросиь. Это же вы отдали наружу объект орма.

> например на не реляционные источники?

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

>а каким образом этот фасад всплывает в жсп?

НАзначение этого фасада обеспечить для presentation layer приемлемый API который абстрагируется от конкретного представления данных и сфокусирован на бизнесметодах. Если надо снять у пользователя бабло со счета - надо передать имя пользователя, сумму и вернуть исключение если бабла нет. Все. Что там внизу - WS, JDBC, EEJB, ORM, JPA или прочий страшный набор букв пользователь знать _не должен_. И выставлять объект типа аккаунт даже в виде Transfer Object наружу _не надо_.

>и где там кстати сказано (по ссылке) что фасад прямо из вью нужно вызывать?

По ссылке там описание паттерна. Я его привел как пример техники. Если вы не можете оценить, что эта техника дает и видите только ее связь с EJB - мои соболезнования. То что там написано это не жуткая инновация в энтерпрайз леере - это принцип как делать нормальные интерфейсы к библиотекам (любым), с минимальным набором простых параметров, и well-defined interfaces, со скрытыми деталями реализации (encapsulation) и всем прочими фишками ООП.

>но только если не использовать его во вью

Да он в основном для него и нужен. Фасад это то что будет выставлено в наружу как вебсервис. А вы что собрались туда выставлять? Контроллер?!

>такое какое вы определите и реализуете.

Вы как специались по полиморфному поведению в ормобъектах конечно не затруднитесь запостить примеры?

>это не более чем оптимизация в конкретной реализации.

Вай вай вай. Если что-то breaks encapsulation - это не много не мало broken encapsulation, и хватит сказок, что энкапсуляции есть просто ее заоптимизировали до полного ее отсутствия.

>только соображения перфоменса

Когда я из соображения перфоманса перепишу программу с С++ на асм - она что останется объектной просто с "соображениями перфоманса"?

>помоему было бы плохо если бы не могли...

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

>ОРМ просто по вашей просьбе работает с вашей моделью. какой объектности тут не хватает?

Хорошо у меня есть свинговый DefaultTableModel - как мне его замапить на ORM?

Еще хочу знать что это за id у меня в объектах - никаких id в доменной области нет. Как это понимать?

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

Вот именно!

> и чего конкретно вам не хватает хотя бы даже и в _такой_ полиморфности?

Отсутвие полиморфного поведения.

>Только вот смысла в полиморфных объектах в RDB очень мало - нет нормальных способов выражать наследование.

Правильно! И хватит рассказывать о том, что это можно сделать как хочешь если никто и никогда так не делает, и в реальной жизни такого нет. Это что-то типа приведения базы данных к 42 нормальной форме в то время как по практическим соображениям так никто не делает.

>дискриминаторы требуют вызывают хранение лишних столбцов,

что вы называете лишними столбцами? а что если рассматривать дискриминатор как ссылку на метаданные о классе? это будет лишним?

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

Где?

>ОО вообще ничерта ни о чем не говорит.

Серьезно?

>ПОсновной принцип ОО - это LSP

5 балов! Ты уже написал письмо Алану Кею, Бучу и прочей братве и объяснил им что LSP основной принцип ООП?

PS: и объекты ORM не обязательно удовлетворяют LSP. Тебе нарисовать?

> Можно прямо в него поведение наляпать - никто не мешает это сдедать.

И ты конечно же готов показать примеры такого поведения? Не теоретические, а приктически покажи кто так делает?

>Только хорошим тоном считается оставлять объекты DAO _чистыми_ - это упрощает _разделение_ поведения и данных.

С ума сойти. И что из этого следует? Например то что объекты орма могут быть представлены простыми структурами? Как например в С# и его анонимных структурах? А в жабе они обектами потому что нихрена нету кроме объектов? Или начнешь утверждат что идея ORM отличается от языка к языку?

Мать - а я что говорю? Я что говорю что в жабе в ормовских абъекта запрещено перекрывать методы? Или extends некомпилится? Я и говорю что по практическим соображениям никто так не делает, и как следствие объекты орма обычно тупой граф данных, и следовательно "объектность" не является аргументом в пользу орма.

>ORM дает мне реальные преимущества - упрощение работы с данными, представляя записи в базе в виде связаной структуры "объектов" (ну называйте их "структурами", что ли).

Классно. С этим кто-то спорил? Нет. Это yet another удобное представление данных. Но ко объектности в терминах ООП оно имеет мало отношения. Но из этого не проистекает что оно плохое или бесполезное.

>а что если рассматривать дискриминатор как ссылку на метаданные о классе? это будет лишним?

Да. Это значит что вы связали данные с особенность реализации.