Здравствуйте!

Перехожу с .Net на Java, возникает масса вопросов....
Например: архитектура ВЕБ-приложений для .NET с которыми я всегда работал выглядела примерно следующим образом:

______________________________
| UI| WEB serv |Win serv |...|
|___|__________|_________|___|
| Сервисный слой |
|____________________________|
| БД |
|____________________________|

Сервисный слой — объекты для вызова хранимых процедур (ХП) из БД, кроме того содержат интерфейсы сущностей из БД, слой осуществляет обработку результата выполнения ХП, если есть необходимость то осуществлял маппинг. Вся бизнес-логика реализована на сервере БД и вызывается сервисным слоем.
Сервисный слой также решал проблемы при одновременном обновлении, а точнее обновлении "устаревших" данных, выдавая нужное исключение

Ну и UI, который "общался" с БД посредством сервисного слоя.

Вся система допускала масштабирование на кластере.
-----------------------------------------------------------
Столкнувшись с Java и иже с ним (EJB,Hibernate и проч.) в упор не понимаю зачем они нужны??!

Часто встречаю использование хибернейта в проекте — в итоге получается, что обновление данных происходит в вызывающем java коде, который загружает запись (объект), изменяет поле и сохраняет объект (запись) в БД.
Это все приводит к тому, что при клике на пункт меню в веб-приложении происходит почти 40 (!!!) обращений к базе (и это рабочая система!, в этом проекте нет ни одной хранимой процедуры!)
Ведь хп были придуманы именно для того, чтобы не было проблем для вызывающего кода, чтобы упростить работу с БД. В итоге получается, что мы идем в обратную сторону, т.к. нам уже сложно писать хранимки и работать с базой?!
При этом утверждается, что хибернейт весьма производителен. Не верю! 40 нескомпилированных запросов не могут быть производительными. Я не говорю о тупости разработчиков, там действительно сделать по-другому через хибернейт очень сложно, но можно написать одну хранимую процедуру.
Можно возразить, что хиберней удобен для маппинга и можно заставить вызывать его те же хранимки. Итого получится — сервисный слой "раздваивается".

О EJB — много читал, и придумал лишь одно применение (но весьма сомнительное) — "толстый" (в смысле обычное GUI или апплет, короче не WEB) клиент, но никак не WEB. Объясните — в каких случаях он применим? Как я понял он, кроме всего прочего, заменяет сервисный слой, но мне с трудом верится, что обойдется без ХП, в итоге — ... в итоге чушь.

Или я чего-то не понимаю? Заранее благодарен за ответ.

Здравствуйте, AlexGK, Вы писали:

Я конечно не эксперт в Java, но постараюсь ответить в меру своего понимания

AGK>Здравствуйте!

AGK>Перехожу с .Net на Java, возникает масса вопросов....
AGK>Например: архитектура ВЕБ-приложений для .NET с которыми я всегда работал выглядела примерно следующим образом:

AGK>______________________________
AGK>| UI| WEB serv |Win serv |...|
AGK>|___|__________|_________|___|
AGK>| Сервисный слой |
AGK>|____________________________|
AGK>| БД |
AGK>|____________________________|

AGK>Сервисный слой — объекты для вызова хранимых процедур (ХП) из БД, кроме того содержат интерфейсы сущностей из БД, слой осуществляет обработку результата выполнения ХП, если есть необходимость то осуществлял маппинг. Вся бизнес-логика реализована на сервере БД и вызывается сервисным слоем.
AGK>Сервисный слой также решал проблемы при одновременном обновлении, а точнее обновлении "устаревших" данных, выдавая нужное исключение

Если я правильно понял, то сервисный слой включал в себя объектную модель приложения (ии ее вообще не было, а были DataSets), и в тоже время средства для работы с базой? Не совсем понятно зачем смешивать перпендикулярные вещи в одном слое? Хранение данных лишь один из аспектов приложения. По мне, так всю бизнес логику пихать в РСУБД которая изначально предназначена для хранения и выборки данных не самое лучшее решение. Хотя бы потому, что бизнес-логика в хранимых процедурах это гарантированный vendor-locking. Да и поддерживать горы SQL-кода сложнее, чем тоже писанное на ООП языке.

AGK>Ну и UI, который "общался" с БД посредством сервисного слоя.

AGK>Вся система допускала масштабирование на кластере.
AGK>-----------------------------------------------------------
AGK>Столкнувшись с Java и иже с ним (EJB,Hibernate и проч.) в упор не понимаю зачем они нужны??!

Hibernate, EJB(Entity), JDO это в большей мере средства абстрагирования объектной модели приложения от конкретного хранилища данных, это может быть реляционная БД (здесь и нужен ORM), объектная БД, обычный XML-файл в конце концов. Если вам нужна сверхвысокая производительность на специальных запросах или хотите работать на низком уровне используйте JDBC напрямую. Зато JDO, Hiberanate помогут вам перенести приложение на другую БД без особых проблем, предоставят возможности по декларативному управлению транзакциями, кэшированием и др. полезными вещами.

AGK>О EJB — много читал, и придумал лишь одно применение (но весьма сомнительное) — "толстый" (в смысле обычное GUI или апплет, короче не WEB) клиент, но никак не WEB. Объясните — в каких случаях он применим? Как я понял он, кроме всего прочего, заменяет сервисный слой, но мне с трудом верится, что обойдется без ХП, в итоге — ... в итоге чушь.

Не понял откуда вы сделали такой вывод? Ведь EJB бывают разные entity, stateful и stateless session beans. И ни одному из них ничего не мешает работать в WEB.

Здравствуйте, Trean, Вы писали:


T>Если я правильно понял, то сервисный слой включал в себя объектную модель приложения (ии ее вообще не было, а были DataSets), и в
T>тоже время средства для работы с базой? Не совсем понятно зачем смешивать перпендикулярные вещи в одном слое?
T>Хранение данных лишь один из аспектов приложения. По мне, так всю бизнес логику пихать в РСУБД которая
T>изначально предназначена для хранения и выборки данных не самое лучшее решение. Хотя бы потому, что
T>бизнес-логика в хранимых процедурах это гарантированный vendor-locking. Да и поддерживать горы SQL-кода сложнее,
T>чем тоже писанное на ООП языке.

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

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

T>Hibernate, EJB(Entity), JDO это в большей мере средства абстрагирования объектной модели приложения от конкретного хранилища данных, это может быть реляционная БД (здесь и нужен ORM), объектная БД, обычный XML-файл в конце концов. Если вам нужна сверхвысокая производительность на специальных запросах или хотите работать на низком уровне используйте JDBC напрямую. Зато JDO, Hiberanate помогут вам перенести приложение на другую БД без особых проблем, предоставят возможности по декларативному управлению транзакциями, кэшированием и др. полезными вещами.

Абстрагироваться от хранилища?! А Вы действительно считаете это возможным??! (в этом случае я говорю про БОЛЬШУЮ систему — Переход от от MS SQL к Oracle будет очень проблематичен и все равно займет много времени и денег, а особенно, когда все размыто в коде...., для этого должна быть очень существенная причина) А оно надо?! И Вы действительно считаете, что система, которая обслуживает ОЧЕНЬ много запросов и итак работает на кластере (16,4-х процессорных) с более-менее приемлимой производительностью, тосле такого "абтсрагирования" не "умрет"?!

Мой сервисный слой органиован в виде COM+ компонентов, поэтому там также декларативное управление транзакциями.
Или может с подобным в Java туговато? Здесь поподробнее, пожалуйста.....

Здравствуйте, AlexGK, Вы писали:

AGK>Здравствуйте, Trean, Вы писали:

AGK>Абстрагироваться от хранилища?! А Вы действительно считаете это возможным??! (в этом случае я говорю про БОЛЬШУЮ систему — Переход от от MS SQL к Oracle будет очень проблематичен и все равно займет много времени и денег, а особенно, когда все размыто в коде...., для этого должна быть очень существенная причина) А оно надо?! И Вы действительно считаете, что система, которая обслуживает ОЧЕНЬ много запросов и итак работает на кластере (16,4-х процессорных) с более-менее приемлимой производительностью, тосле такого "абтсрагирования" не "умрет"?!

Я разве сказал, что она не "умрет", я ж не знаю ни специфики запросов ни объема данных, в исходном посте про это не было ничего. Если нужна супер производительность используйте хранимки с оптимизацией запросов под конкретную БД. Возможно даже удасться прикрутить Hibernate или JDO в них такая возможность есть, можно и свои запросы указывать AFAIK, иначе JDBC+Spring. Нет серебряной пули, каждое средство надо применять под свои цели. Если у меня нет терабайтов передаваеммых данных и тысяч одновременных запросов, зачем мне париться с SQL, когда я реализую модель в классах и все, остально за меня сделает ORM-средство?

AGK>Мой сервисный слой органиован в виде COM+ компонентов, поэтому там также декларативное управление транзакциями.
AGK>Или может с подобным в Java туговато? Здесь поподробнее, пожалуйста.....

Сомневаюсь, что в Java есть проблемы — стоит лишь набрать declarative transaction management и вывалится куча ссылок для J2EE. В JDBC управление транзакциями (создание, коммиты, откаты) прописывается ручками в коде, в J2EE приложениях как правило в соотв. дескрипторе приложения.

Здравствуйте, Trean, Вы писали:

T>Здравствуйте, AlexGK, Вы писали:

AGK>>Здравствуйте, Trean, Вы писали:


T>Я разве сказал, что она не "умрет", я ж не знаю ни специфики запросов ни объема данных, в исходном посте про это не было ничего. Если нужна супер производительность используйте хранимки с оптимизацией запросов под конкретную БД. Возможно даже удасться прикрутить Hibernate или JDO в них такая возможность есть, можно и свои запросы указывать AFAIK, иначе JDBC+Spring. Нет серебряной пули, каждое средство надо применять под свои цели. Если у меня нет терабайтов передаваеммых данных и тысяч одновременных запросов, зачем мне париться с SQL, когда я реализую модель в классах и все, остально за меня сделает ORM-средство?

Согласен, Вы правы... Тогда интересует такой вопрос: часто встречаю, что EJB "тяжеловесная" технология и смысла для относительно небольших приложений ее применять нет.... А что же получается, что для больших систем уже нельзя — слишком большая "плата" (сам не замерял, это проблематично сделать, но можно "прикинуть")...

В общем конечные вопросы такие:
когда нужно и можно применять EJB, когда нельзя или нет необходимости.
Когда допустимо применять ORM, когда нет и т.п.?
Какова "плата" за применение EJB или Hibernate?

Здравствуйте, AlexGK, Вы писали:

AGK>Здравствуйте, Trean, Вы писали:

T>>Здравствуйте, AlexGK, Вы писали:

AGK>>>Здравствуйте, Trean, Вы писали:


T>>Я разве сказал, что она не "умрет", я ж не знаю ни специфики запросов ни объема данных, в исходном посте про это не было ничего. Если нужна супер производительность используйте хранимки с оптимизацией запросов под конкретную БД. Возможно даже удасться прикрутить Hibernate или JDO в них такая возможность есть, можно и свои запросы указывать AFAIK, иначе JDBC+Spring. Нет серебряной пули, каждое средство надо применять под свои цели. Если у меня нет терабайтов передаваеммых данных и тысяч одновременных запросов, зачем мне париться с SQL, когда я реализую модель в классах и все, остально за меня сделает ORM-средство?

AGK>Согласен, Вы правы... Тогда интересует такой вопрос: часто встречаю, что EJB "тяжеловесная" технология и смысла для относительно небольших приложений ее применять нет.... А что же получается, что для больших систем уже нельзя — слишком большая "плата" (сам не замерял, это проблематично сделать, но можно "прикинуть")...

У EJB 2.0 Entity Beans были серьезные проблемы с производительностью, сравнительно недавно вышли EJB 3.0, которые, насколько я знаю, разрабатывались на основе опыта разработчиков Hibernate.

AGK>В общем конечные вопросы такие:
AGK>когда нужно и можно применять EJB, когда нельзя или нет необходимости.
AGK>Когда допустимо применять ORM, когда нет и т.п.?
AGK>Какова "плата" за применение EJB или Hibernate?

Лучше спросить в форуме Java (а лучше эту туда переместить), там я думаю дадут квалифицированный ответ.
Вот еще книжка хорошая:
Expert One-on-One J2EE Design and Development Там в том числе и про EJB и про то когда и как без него обойтись.

Здравствуйте, AlexGK,
Загляните сюда

Автор: mr_dino
Дата: 09.06.06

.

Здравствуйте, Trean, Вы писали:


T>Я разве сказал, что она не "умрет", я ж не знаю ни специфики запросов ни объема данных, в исходном посте про это не было ничего. Если нужна супер производительность используйте хранимки с оптимизацией запросов под конкретную БД. Возможно даже удасться прикрутить Hibernate или JDO в них такая возможность есть, можно и свои запросы указывать AFAIK, иначе JDBC+Spring. Нет серебряной пули, каждое средство надо применять под свои цели. Если у меня нет терабайтов передаваеммых данных и тысяч одновременных запросов, зачем мне париться с SQL, когда я реализую модель в классах и все, остально за меня сделает ORM-средство?


T>У EJB 2.0 Entity Beans были серьезные проблемы с производительностью, сравнительно недавно вышли EJB 3.0, которые, насколько я знаю, разрабатывались на основе опыта разработчиков Hibernate.

T>Лучше спросить в форуме Java (а лучше эту туда переместить), там я думаю дадут квалифицированный ответ.
T>Вот еще книжка хорошая:
T>Expert One-on-One J2EE Design and Development Там в том числе и про EJB и про то когда и как без него обойтись.


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

Здравствуйте, AlexGK, Вы писали:

AGK>Большое спасибо за ответы. Я попробую применить EJB, особенно если все это "безобразие" запихнуть в специальный слой, который и будет вызывать UI, туда же можно будет впихнуть, если очень хочется вызовы хп и другое.

Я бы взял что-нить более проверенное, Hibernate или JDO, а то последняя редакция EJB несколько месяцев назад юыла выпущена, и глюки в reference implementation возможны. Кроме того я слышал, не все довольны изменениями, конкретики не знаю, лучше поискать прежде отзывы, прежде чем сразу использовать новую технологию.

Здравствуйте, AlexGK, Вы писали:

AGK>Здравствуйте!

AGK>Перехожу с .Net на Java, возникает масса вопросов....
AGK>Например: архитектура ВЕБ-приложений для .NET с которыми я всегда работал выглядела примерно следующим образом:

AGK>______________________________
AGK>| UI| WEB serv |Win serv |...|
AGK>|___|__________|_________|___|
AGK>| Сервисный слой |
AGK>|____________________________|
AGK>| БД |
AGK>|____________________________|

Для начала пару слов о EJB.
EJB — это стандарт для построения распределенных ООП приложений, входит в состав J2EE.
В сервере приложений, котороый следует стандарту J2EE, имеется EJB-контейнер, котороый обслуживает EJB-компоненты.
В спецификации EJB существуют три типа компонент

1. Session bean — компоненты, представляющие какие-либо действия, реализует бизнес-логику, алгоритмы или процессы
Существуют два типа session bean:

* Stateless session bean — бин не имеющий состояния. Можно представить его в виде класса, в котором существую только методы, и не сществует полей, сохраняемых между вызовами методов.
Например: бин, реализующий калькулятор, может иметь метод сложить(x, y), вызываем его — получаем ответ.
* Statefull session bean — бин имеющий состояния (в течение сеанса работы с сервером). Здесь уже работа метода бина зависит от его текущего состояния (например, от значения его полей). Тот же пример с калькулятором: у бина могут быть методы ввести(x), ввести("+"), ввести(y), получитьОтвет(). Для работы такого бина необходимо сохранять промежуточное значения между вызовами методов.
2. Entity bean — используется для постоянного хранения сущностей (как правило, в БД). Пример (хранение данных о Студенте — StudentBean)
Также существуют два типа entity bean:

* Container-managed persitence (CMP) — когда за хранение бина в базе отвечает EJB-контейнер, т.е. работой с БД по созданию, изменению, удалению и поиску этого бина занимается сервер приложений (EJB-контейнер).
* Bean-managed persistence (BMP) — когда за хранение бина в базе отвечает сам компонент. Он может вызывать хранимые процедуры на сервере, или сформировать свой SQL запрос для обновления данных, или использовать OR-mapper. С помощью этого бина можно также частично абстрагироваться от базы или же взять полное управление хранением на себя.
3. Message-driven bean — используется для обработки асинхронных сообщений

AGK>Сервисный слой — объекты для вызова хранимых процедур (ХП) из БД, кроме того содержат интерфейсы сущностей из БД, слой осуществляет обработку результата выполнения ХП, если есть необходимость то осуществлял маппинг. Вся бизнес-логика реализована на сервере БД и вызывается сервисным слоем.
AGK>Сервисный слой также решал проблемы при одновременном обновлении, а точнее обновлении "устаревших" данных, выдавая нужное исключение
AGK>Ну и UI, который "общался" с БД посредством сервисного слоя.
AGK>Вся система допускала масштабирование на кластере.
AGK>-----------------------------------------------------------

В вашем случае бизнес-логика приложения реализована в СУБД, а задача сервисного слоя — забрать данные из СУБД и подготовить их для UI-слоя.
Ваш сервисный слой фактически аналогичен ВMP (см.выше).

Другой подход (более распространенный в J2EE) — реализация бизнес-логики на сервере приложений:
UI-клиент (или браузер + JSP) --- Сервер-приложений --- БД

* БД отвечает за хранение данных
* EJB-компоненты в сервере приложений реализуют бизнес-логику
* сервер приложений отвечает за управление компонентами
* UI-клиент отвечает за интерфейс с пользователем

AGK>Столкнувшись с Java и иже с ним (EJB,Hibernate и проч.) в упор не понимаю зачем они нужны??!

Для чего это надо:
Entity bean (BMP и CMP) и Hibernate — для сохранения объектов в БД, а также для абстрагирования от прямой работы с БД
EJB вообще (Entity bean, Session bean, MDB) — для реализации бизнес-логики
Сервер приложений — для обеспечения транзакций, кэширования, безопасности, масштабирования и т.д.

AGK>Часто встречаю использование хибернейта в проекте — в итоге получается, что обновление данных происходит в вызывающем java коде, который загружает запись (объект), изменяет поле и сохраняет объект (запись) в БД.
AGK>Это все приводит к тому, что при клике на пункт меню в веб-приложении происходит почти 40 (!!!) обращений к базе (и это рабочая система!, в этом проекте нет ни одной хранимой процедуры!)
AGK>Ведь хп были придуманы именно для того, чтобы не было проблем для вызывающего кода, чтобы упростить работу с БД. В итоге получается, что мы идем в обратную сторону, т.к. нам уже сложно писать хранимки и работать с базой?!
AGK>При этом утверждается, что хибернейт весьма производителен. Не верю! 40 нескомпилированных запросов не могут быть производительными. Я не говорю о тупости разработчиков, там действительно сделать по-другому через хибернейт очень сложно, но можно написать одну хранимую процедуру.
AGK>Можно возразить, что хиберней удобен для маппинга и можно заставить вызывать его те же хранимки. Итого получится — сервисный слой "раздваивается".
Сила hibernate и Entity bean — в абстрагировании от БД, т.е. работа с персистентными объектами, как с обычными. Плюс — кэширование информации.
Что можно сказать про указанные 40 запросов? Это ведь ни о чем не говорит: можно ли получить информацию за меньшее количество запросов? какова сложность загружаемых (записываемых) объектов? какие настройки мэппинга? сколько будет запросов к БД при втором аналогичном "клике"? Все зависит от сложности персистентных объектов их, мэппинга, а также и от архитектуры приложения в целом.
А если легче написать хранимую процедуру — то почему бы ее не написать? (правда, надо учесть дополнительные трудности при сопровождении). Но большую часть работы с БД не придется делать вручную.

В целом, для относительно простых объектов вполне достаточно CMP (или Hibernate). Это позволит не углубляться в детали БД. Для более сложных объектов придется использовать хранимые процедуры или SQL запросы (например, с помощью BMP).

AGK>О EJB — много читал, и придумал лишь одно применение (но весьма сомнительное) — "толстый" (в смысле обычное GUI или апплет, короче не WEB) клиент, но никак не WEB. Объясните — в каких случаях он применим? Как я понял он, кроме всего прочего, заменяет сервисный слой, но мне с трудом верится, что обойдется без ХП, в итоге — ... в итоге чушь.
Кроме EJB-контейнера сервер приложений содержит Web-контейнер, который управляет JSP-страницами web-приложения.
Результатом работы JSP является HTML или XML, который передается браузеру и отображается пользователю.
При работе страница JSP может обратиться к EJB-компонентам для вызовов методов, реализующих бизнес-логику.
Т.е. вместо "толстого клиента у пользователя + бизнес-логика на сервере приложения" имеем "браузер у пользователя + JSP и бизнес-логика на сервере".

AGK>Или я чего-то не понимаю? Заранее благодарен за ответ.

Надеюсь, ответ чем-то поможет...

Здравствуйте, Beam, Вы писали:

По поводу вот этого комментария:

B>А если легче написать хранимую процедуру — то почему бы ее не написать? (правда, надо учесть дополнительные трудности при сопровождении). Но большую часть работы с БД не придется делать вручную.

Длинное вступление и короткий вопрос (правда он относится не к Джава Хибернейту, а к Нхибернейту).
У меня была ситуация, когда на небольшом пилотном проекте (которым мне короткое время пришлось поруководить) вся команда (3 опытных дэва, все опытнее меня) заявила хором, что хочет во что бы то ни стало юзать NHibernate. Я про НХибернейт ровным счетом ничего не знал, но после часа обсуждений, я согласился с тимом и сам засел за его изучение.
И что получилось. Обсудили мой план, все согласились, при этом ситуация пилотного проекта такая, что нужно уже через месяц показать заказчику proof of concept. И вот проходит неделя, у нас по плану уже чуть ли не три псевдоработающих модуля должны быть готовы, а весь тим занимается "настройкой НХибернейта". Мне остается только это выслушивать, потому что я трачу все время на разговоры по телефону с ПМ-ом, которому я пытаюсь объяснить, что лучше день потерять, потом за 5 минут долететь (чему я сам уже не верю), и с дизайнером, который со скоростью звука дизайнит прикрасные формы, которые только и ждут, как бы их оживили. Вообщем оказалось, что экспириенс в НХибернейте у всех весьма посредственный, а кроме того, как я понимаю, для маленького пилотного проекта, это как из пушки по воробьям (правда мне все рассказывали, что мы потом сэкономим время когда из пруф ов концепта будет вырастать большая стройная система).
Вообщем к концу недели мне все это надоедает, я собираю митинг, показываю им план, в ответ слышу нытье, что им до сих пор не удалось разобраться с мени-то-мени рилейшеншипсами. Тогда я сажусь за комп и создаю хранимую процедуру. Шок. Один парень, мне казалось, хотел меня ударить. Такое ощущение, как будто я его оскорбил или плюнул в душу или что-то такое. "Как... как можно смешивать Нхибернейт и хранимые процедуры?". Вообщем в итоге один человек остался доконфигурировать нхибернейт, а остальным я предложил пока еще есть время строчить ХП.

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

Так вот все это длинное вступление (давно хотелось поделиться) и короткий вопрос — как считаете можно смешивать ORM и ХП?

Здравствуйте, Ael, Вы писали:

Ael>Так вот все это длинное вступление (давно хотелось поделиться) и короткий вопрос — как считаете можно смешивать ORM и ХП?
Нужно.

Здравствуйте, Ael, Вы писали:

"... Такое ощущение, как будто я его оскорбил или плюнул в душу или что-то такое..."

А что такое программирование? Освоение новых фичей — нашел игрушку в интернете, разломал, выбросил.

Здравствуйте, Ael, Вы писали:




Ael>У меня была ситуация, когда на небольшом пилотном проекте (которым мне короткое время пришлось поруководить) вся команда (3 опытных дэва, все опытнее меня) заявила хором, что хочет во что бы то ни стало юзать NHibernate. Я про НХибернейт ровным счетом ничего не знал, но после часа обсуждений, я согласился с тимом и сам засел за его изучение.
Скажите пзх какую версию NHibernate использовали тогда ?

Ael>И что получилось. Обсудили мой план, все согласились, при этом ситуация пилотного проекта такая, что нужно уже через месяц показать заказчику proof of concept. И вот проходит неделя, у нас по плану уже чуть ли не три псевдоработающих модуля должны быть готовы, а весь тим занимается "настройкой НХибернейта".
Эээ что значит настройка???
там настройки всего паратройка строчек в конфиге или это вы про ХМL маппинги ?

Ael>Мне остается только это выслушивать, потому что я трачу все время на разговоры по телефону с ПМ-ом, которому я пытаюсь объяснить, что лучше день потерять, потом за 5 минут долететь (чему я сам уже не верю), и с дизайнером, который со скоростью звука дизайнит прикрасные формы, которые только и ждут, как бы их оживили. Вообщем оказалось, что экспириенс в НХибернейте у всех весьма посредственный, а кроме того, как я понимаю, для маленького пилотного проекта, это как из пушки по воробьям (правда мне все рассказывали, что мы потом сэкономим время когда из пруф ов концепта будет вырастать большая стройная система).
Только ИМХО в том случае если в пилотном проекте была более менее полно реализованы классы доменной моджели — тогда да.
Ael>Вообщем к концу недели мне все это надоедает, я собираю митинг, показываю им план, в ответ слышу нытье, что им до сих пор не удалось разобраться с мени-то-мени рилейшеншипсами.

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

Ael>Тогда я сажусь за комп и создаю хранимую процедуру. Шок. Один парень, мне казалось, хотел меня ударить. Такое ощущение, как будто я его оскорбил или плюнул в душу или что-то такое. "Как... как можно смешивать Нхибернейт и хранимые процедуры?". Вообщем в итоге один человек остался доконфигурировать нхибернейт, а остальным я предложил пока еще есть время строчить ХП.

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

Ael>Хотя если честно в своей идее Нхибернейт мне очень понравился, просто у нас готовить его никто не умел.
Да там по-моему практически нечего серьезно готовить затыки только на первых порах ну недели 2 максимум
а весч действительно стоящая!!!!
Ael>Так вот все это длинное вступление (давно хотелось поделиться) и короткий вопрос — как считаете можно смешивать ORM и ХП?
ORM и хранимки можно только вот весь вопрос в том НУЖНО ли их серьезно смешивать ?
Если где то возникает проблема с быстродействием то можно переписать это узкое место через хранимки а так вобщем то
использовать или ORM или ХП по отдельности. Ну конечно если дело касается тяжелых отчетов то ОРМ тут не помощник
тут только БД + хранимки + Бубен из кожи того пользователя которому этот отчет понадобился

Здравствуйте, Ael, Вы писали:

Ael>Хотя если честно в своей идее Нхибернейт мне очень понравился, просто у нас готовить его никто не умел.

Скорее всего дело в том, что БД была спроектирована без учета объектной модели. Замапить объектную модель в базу легко, а вот обратная задача далеко не всегда тривиальна. Учитывая, что по твоим словам, с ORM инструментами никто из вас до этого не работал, это наиболее вероятный вариант.

Ael>Так вот все это длинное вступление (давно хотелось поделиться) и короткий вопрос — как считаете можно смешивать ORM и ХП?

Ничему не противоречит. Более того, в ряде случаев это позволяет существенно упростить разработку ценой некоторой "размазанности" логики между БД и кодом. С другой стороны при правильно подходе эту размазанность легко можно локализовать.

Здравствуйте, Ael, Вы писали:

Ael>Хотя если честно в своей идее Нхибернейт мне очень понравился, просто у нас готовить его никто не умел.

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

Ael>Так вот все это длинное вступление (давно хотелось поделиться) и короткий вопрос — как считаете можно смешивать ORM и ХП?

более абстрактно можно было бы спросить: "А какова стратегия развития приложения: плясать будем от БД или сверху?"

я встречал разработчиков с БД-driven логикой мышления. т.е. они быстро готовы создавать таблицы и ХП. могу даже уточнить, что когда-то сам был таким. основная проблема с использованием такого подхода — как в проекте разработки, так и в проекте сопровождения нужен человек, который разбирается в языке программирования ХП конкретной СУБД. для разработки это еще терпимо, для сопровождения — имхо нет. говорю как человек, который занимается поддержкой такого продукта фактически я имею примерно в два раза больше работы при внесении изменений и дополнений, чем имел бы, будь оно на hibernate-как-я-его-использую.

если же проект делается "сверху", то ХП места уже не находится. безусловно, мне потребовалось некоторое время, чтобы пройти путь выработки удачных подходов в выборе мэппинга и приемов создания объектов уровня языка (java). но имея в запасе арсенал создание приложения становится комфортным. безусловно, такой подход не избавляет от необходимости иметь специалиста по БД, но сводит его задачи в основном к отслеживанию неэффективно выполняющихся запросов (я при этом не имею в виду администратора, который потом будет поддерживать сервер на стороне заказчика)

ps. у БЛ на уровне ХП есть еще одна неочевидная с первого взгляда неприятность — затруднена генерация локализуемых сообщений об ошибках. скажем, на java возможности i18n/l10n настолько развиты, что ими хочется пользоваться вовсю. в том числе, переводить сообщения об ошибках с параметрами. они характеризуются тем, что на разных языках а) порядок параметров зависит от порядка построения фразы, б) параметры могут по-разному форматироваться (я имею в виду всякие десятичные разделители, 12-24-время и т.п.). городить что-то подобное на уровне ХП — бред, а организовывать подъем всей информации об ошибке (код, параметры) из ХП — имхо тяжело (возможно и есть развитые средства сопряжения языков СУБД с такими ЯП как java, c++, но мне они неизвестны, "наглядный" вариант jbdc-вызова ХП только показывает масштабы такого гемора). если же оперирование объектами БД идет на уровне java — под рукой все средства, чтобы сформировать нормальное сообщение.

Здравствуйте, AlexGK, Вы писали:

AGK>Здравствуйте!

AGK>Перехожу с .Net на Java, возникает масса вопросов....
AGK>Например: архитектура ВЕБ-приложений для .NET с которыми я всегда работал выглядела примерно следующим образом:

AGK>Сервисный слой — объекты для вызова хранимых процедур (ХП) из БД, кроме того содержат интерфейсы сущностей из БД, слой осуществляет обработку результата выполнения ХП, если есть необходимость то осуществлял маппинг. Вся бизнес-логика реализована на сервере БД и вызывается сервисным слоем.
AGK>Сервисный слой также решал проблемы при одновременном обновлении, а точнее обновлении "устаревших" данных, выдавая нужное исключение

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

Тогда при переводе этого на J2EE не нужно никаких сложностей из EJB, достаточно переписать сервисный слой на stateless бинах или вообще на сервлетах (что зачастую проще и надежнее).

Вообще, подход в J2EE (как в EJB, так и во всяких ОRB) — принципиально другой.
БД используется только для хранения данных, а вся бизнес-логика реализуется на сервере приложений, при необходимости получащих отдельные сущности предметной области из соответствующего хранилища (и в конце транзакции сохранящие их обратно).При этом, например, часто используемые элементы предметной области кэшируются (средствами EJB).

Плюсы:
Низкая зависимость от конкретной БД, возможность исползовать слабые сервера БД (так как ничего кроме простейших select и insert они, по идее, не делают). Легко реализовывать partioning, в том числе и на беслпатных серверах (т.е. вручную).
Легкое масштабирование промежуточного слоя, при хорошем проектировании почти линейно от числа серверов.
Низкая стоимость софта даже для тяжелых решений (ну, обычно можно вообще обойтись бесплатным софтом — от бесплатных лицензий на БД до opensource серверов).
Легко модифицировать логику (для меня этот плюс важнее всех остальных, вместе взятых). Все-таки быстро менять сложную бизнес-логику, написанную в хранимых процедурах (да еще с реализацией, например, зависимости поведения от пользовательских настроек, сделанное самостоятельно наследование и т.п.) очень и очень сложно, особенно на рабочем сервере без остановки работы.

Минусы:
Реализация кластеризации на большинстве EJB серверах (BMP/CMP бины, понятное дело) весьма посредственная — так как возникают проблемы с синхронизацией и совместным обновлением кэшей. Впрочем, у кластеров на БД те же самые проблемы и с аналогичными решениями. Впрочем, Oracle говорит, что в его EJB сервере производится синхронизация объектов в памяти на всех машинах кластера, но руками не пробовал, не знаю.

Здравствуйте, Trean, Вы писали:

T>Здравствуйте, AlexGK, Вы писали:

T>Я бы взял что-нить более проверенное, Hibernate или JDO, а то последняя редакция EJB несколько месяцев назад юыла выпущена, и глюки в reference implementation возможны. Кроме того я слышал, не все довольны изменениями, конкретики не знаю, лучше поискать прежде отзывы, прежде чем сразу использовать новую технологию.

Я решил использовать EJB3 — не знаю кому как, но мне эта версия понравилась больше, чем 2.1, а вот отзывы действительно поищу, спасибо. В общем, потом напишу свои домыслы по поводу него

Здравствуйте, Аноним, Вы писали:

Cпасибо за ответ. В принципе я уже понял что к чему... Действительно, определенные выгоды есть и весьма ощутимые.
Другой вопрос во сколько обходится такой подход? Кто-нибудь пробовал замерять? КИнтье линк, если есть, сам я попробую проверить на разных выборках/вставках/апдейтах, о результатах напишу. По идее, конечно, сильной потери производительности не должно быть, если грамотно организовать логику и миимимзировать лишние запросы к базе... но увидим.

Здравствуйте, Ael, Вы писали:


Ael>Так вот все это длинное вступление (давно хотелось поделиться) и короткий вопрос — как считаете можно смешивать ORM и ХП?

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