Здравствуйте, Аноним, Вы писали:
А>Приветствую. Столкнулся со следующей ситуацией, на новом проекте используется EJB, я с ним раньше не работал. А>Более-менее разобрался как получить доступ к бину, вызывать методы и т.д. Теперь возникла проблема как это всё использовать, имеем стандартное веб-приложение. Собратья по проекту говорят, что надо всю логику положить в EJB, в их коде это выглядить как пара десятков session-bean'ов на проект (размером в несколько килострок), где намешана логика, работа с DB и т.п. Говорят, что в бинах удобно настраивается транзакционность, поэтому работа с БД должна вестись оттуда. Пока у меня были преимущественно DAO-методы, я не напрягался, клал их в соответствующий бин и вызывал из веб-части. Сейчас в программу предстоит добавить довольно много логики, мне кажется неразумным каждый класс оформлять в бин (например если это обычный java-класс, заполняющий какую-нибудь структурку, никаких операций с базой и вызовов извне и т.д.).
А>Подскажите, что можно почитать чтобы понять как лучше организовать код с использованием session beans. Я склоняюсь к тому, чтобы в бины вынести интерфейс ко всему, что вызывается из веб-части (т.е. обработчики всего в вебе просто получают соответствующий бин и вызывают его метод). Логику, имхо, можно хранить в обычных классах, стоит ли оформлять DAO в виде EJB (используем JDBC)? Спасибо!
Вообще удивительно. Ты совсем недавно используешь EJB а уже задался вопросом который мучает всех начиная еще с первых версий EE спецификации. Да, как раз почти все так и делают. Всю логику переносят в POJO, а session beans делают транспортом и местом котроля транцакций и безопасности. Вообще этот фундаментальный вопрос и эта техника построения приложения был предпосылкой для создания spring framework, которая, в общем то, и реализует подобный подход только в более общем виде.
Дизайн приложения с использованием EJB
От:
Аноним
Дата:
17.11.08 20:20
Оценка:
Приветствую. Столкнулся со следующей ситуацией, на новом проекте используется EJB, я с ним раньше не работал.
Более-менее разобрался как получить доступ к бину, вызывать методы и т.д. Теперь возникла проблема как это всё использовать, имеем стандартное веб-приложение. Собратья по проекту говорят, что надо всю логику положить в EJB, в их коде это выглядить как пара десятков session-bean'ов на проект (размером в несколько килострок), где намешана логика, работа с DB и т.п. Говорят, что в бинах удобно настраивается транзакционность, поэтому работа с БД должна вестись оттуда. Пока у меня были преимущественно DAO-методы, я не напрягался, клал их в соответствующий бин и вызывал из веб-части. Сейчас в программу предстоит добавить довольно много логики, мне кажется неразумным каждый класс оформлять в бин (например если это обычный java-класс, заполняющий какую-нибудь структурку, никаких операций с базой и вызовов извне и т.д.).
Подскажите, что можно почитать чтобы понять как лучше организовать код с использованием session beans. Я склоняюсь к тому, чтобы в бины вынести интерфейс ко всему, что вызывается из веб-части (т.е. обработчики всего в вебе просто получают соответствующий бин и вызывают его метод). Логику, имхо, можно хранить в обычных классах, стоит ли оформлять DAO в виде EJB (используем JDBC)? Спасибо!
Здравствуйте, Аноним, Вы писали: А> Логику, имхо, можно хранить в обычных классах, стоит ли оформлять DAO в виде EJB (используем JDBC)?
Логику хранить в виде pojo хорошо, но возникает проблема разрешения зависимостей — ejb-инжекции работать не будут, а при отсутствии спринга прийдётся дополнительно поработать руками.
Насчёт dao, ejb и jdbc — имеется в виду доступ к БД через jdbc-драйвер или же работа с данными только через jdbc-код? Отчего бы не взять пул коннеций у апп. сервера и не использовать бы какую-нибудь JPA-реализацию? Ведь и поддержка транзакций в EJB на использование JPA завязана, не на нативный jdbc-код.
Здравствуйте, Nicht, Вы писали:
N>Вообще удивительно. Ты совсем недавно используешь EJB а уже задался вопросом который мучает всех начиная еще с первых версий EE спецификации.
Если есть нормальный опыт программирования на любом языке в команде, которая уделяет внимание архитектуре, а не тонкостям технологий, то ничего удивительного нет, вопросы вполне очевидные. А если технологии первичны, то так и будем писать всю логику в одном классе на тысячи строк без разделения на слои.
