Технология EJB3 представляет из себя смесь различных технологий:
- JPA, которая чаще всего используется с какой-нибудь ORM вроде Hibernate, TopLink или iBatis
- IoC контейнер, причем не полный
- Вполне приличный AOP
- Автогенерацию веб сервисов
Как правило EJB3 применяют в связке с каким-нибудь MVC фреймворком, вроде JavaFaces. Основным недостатком такой схемы является то, что все эти фреймворки построены на основе Servlet API, что само по себе было бы неплохо, если бы JPA сессия не терялась при выходе из контекста EJB3, что за собой ведет проблемы lazy инициализации объектов бизнес модели.
Долго думаю над тем, как можно применять EJB3, при том, чтобы недостатки технологии не мешали разработке. Я пришел к выводу, что необходимо полностью отказаться от слоев, в которых не действует сессия JPA, т.е. от слоя представления. Слой представления же должен поддерживать связь с EJB контейнером посредством веб сервисов. Преимущества такой схемы:
- Слой представления может быть реализован на любом динамическом языке, вроде Python, Ruby, Perl
- Четкое выделение бизнес логики, позволит быстрее и проще ее тестировать
- Более простое сопряжение с другими системами
Причем последний пункт считаю особо важным. Работая в сфере финансовых операций часто приходится объединять между собой различные системы. Для примера приведу случай из собственного опыта. Наша компания работает в сфере финансовых операций, а именно электронных платежей. Основным нашим продуктом является платежная система на ряд сервисов Кыргызстана. Благодаря тому, что бизнес логика доступна через веб сервисы мы легко можем ее соединить с другими сервисами компании.
Комментариев нет:
Отправить комментарий