Для вашего случая использования, когда приложение работает на одном сервере, а база данных работает на другом, выбор между EJB и Spring не имеет значения.Это поддерживается любой платформой, будь то приложение Java SE, простой контейнер сервлетов, такой как Tomcat или Jetty, PHP, Ruby on Rails и т. Д.
Для этого не требуется никакого явного удаленного взаимодействия.Вы просто определяете источник данных, указываете URL, где живет ваш сервер БД, и все.
Тем не менее, и EJB, и Spring Beans облегчают работу с источниками данных.Они оба помогают вам определить источник данных, внедрить его в bean-компоненты и управлять связанными с ними транзакциями.
Из этих двух EJB (и Java EE в целом) является более легковесным и больше соответствует соглашению по принципу конфигурации.Spring требует большего многословия для получения одних и тех же вещей и во многом зависит от XML-файлов, которые могут быстро стать очень большими и громоздкими.Оборотная сторона медали в том, что Spring может быть менее волшебным, и вы можете чувствовать себя более уверенно, имея все, что вы хотите изложить.
Другая проблема заключается в способах разработки EJB и Spring.
EJB бесплатен (как в бесплатном пиве), с открытым исходным кодом и не является собственностью.Существуют реализации EJB, создаваемые некоммерческими организациями (Apache), компаниями с открытым исходным кодом (Redhat / JBoss) и глубоко коммерческими предприятиями с закрытым исходным кодом (IBM).Я лично избегал бы последнего, но каждому свое.
Spring, с другой стороны, бесплатный и с открытым исходным кодом, но сильно запатентован.Есть только одна компания, которая делает Spring, и это Springsource.Если вы не согласны с Родом, тогда вам не повезло.Это не обязательно плохо, но есть разница, о которой вы могли бы знать.
Делать все @ аннотации всегда хорошо?конфигурация никогда не нужна?
Это действительно бесконечные дебаты.Некоторые утверждают, что XML трудно поддерживать, другие утверждают, что аннотации загрязняют в противном случае чистую модель POJO.
Я думаю, что аннотирование bean-компонента как EJB-компонента без сохранения состояния (@Stateless) или объекта JPA (@Entity)более аккуратно сделано с использованием аннотаций.То же самое касается инъекций зависимостей @EJB или @Inject.С другой стороны, я предпочитаю, чтобы именованные запросы JPQL были в XML-файлах, а не в аннотациях, а инъекции, которые представляют чистые данные конфигурации (например, максимальное значение для чего-либо), также были в XML.
В Java EEкаждая аннотация также может быть указана в XML.Если присутствуют и аннотация, и эквивалент XML, XML отменяет аннотацию.Это делает его действительно удобным, чтобы начать с аннотации для случая по умолчанию, но переопределить его позже через XML для конкретного случая использования.
В настоящее время предпочтение в Java EE, по-видимому, больше к (простым) аннотациям в сочетании сбольшое количество соглашений по конфигурации.