Приложение Oracle / Java, рекомендуемые архитектуры

Question

Я работаю над настольным Java-приложением, которое должно подключаться к базе данных Oracle через прокси-сервер, который может быть сервлетом, EJB или чем-то еще, что вы можете предложить.

Мой вопрос таков: какую архитектуру следует использовать?

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

2. Корпоративное приложение с EJB-компонентами и удаленными интерфейсами для доступа к базе данных

3. Любые другие опции, о которых я не задумывался.

Спасибо

Answer 1

В зависимости от масштабируемости решения, вы можете сделать выбор.

1. EJB (3) может сделать хороший выбор, но тогда вам нужен полноценный сервер приложений.

2. Вы можете подключиться напрямую, используя jdbc, но это откроет URL-адрес db (expose, так как в каждом клиентском настольном приложении будет подключение к БД. Вы не сможете объединиться и потерять многогибкости).Я бы не советовал идти по этому пути, если ваше приложение не очень простое.

3. Вы можете создать сервлет, который будет действовать как прокси, но он утомителен и не так масштабируем.Вам нужно будет написать много кода на обоих концах

4. Я бы порекомендовал создать службу на основе REST, которая выполняет требуемые операции с БД, и использовать ее в приложении для настольных компьютеров.

Answer 2

Начните с простого. Я бы начал с простого решения на основе сервлетов / JDBC и обеспечил бы полную работоспособность системы. С этой точки зрения рассмотрим:

1. хотите ли вы использовать объединение пулов (скорее всего). Рассмотрим C3P0 / Apache DBCP
2. Вы хотите использовать такие рамки, как Spring ? Вы можете перейти к этому постепенно и начать с использования возможностей сервлета MVC, IoC и т. Д. И использовать более сложные решения по мере необходимости
3. Хотите использовать ORM? У вас есть сложные графы объектов, которые вы сохраняете / запрашиваете, и упростит ли ORM вашу разработку?

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

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

Answer 3

У меня большой успех с использованием Spring-remoting и подходом, основанным на сервлетах. Это также отличная установка для разработки, поскольку вы можете легко протестировать свой код без развертывания в веб-контейнере.

• Вы начинаете с определения сервисного интерфейса для извлечения / хранения ваших данных (POJO).
• Создайте реализацию, которая может использовать ORM, прямую JDBC или некоторую библиотеку пула (предоставленный контейнер или стороннюю). Это не имеет отношения к удаленному развертыванию.
• Разработка приложения, которое использует этот сервис напрямую (без развертывания на сервере).
• Когда вы будете удовлетворены всем, заверните свою реализацию в войну и разверните ее с помощью Spring DispatcherServlet. Если вы используете maven, это можно сделать с помощью war plugin
• Настройка рабочего стола для использования сервиса через удаленное взаимодействие Spring.

Я обнаружил, что возможность легко разрабатывать код путем запуска службы как части приложения является огромным преимуществом по сравнению с разработкой / отладкой чего-либо, выполняющегося на сервере. Я использовал этот подход как с EJB, так и без него, хотя в нашем конкретном случае к EJB по-прежнему обращались через сервлет. Только сервисные сервисные вызовы использовали EJB напрямую (также используя удаленное взаимодействие Spring).

Answer 4

Прямое использование JDBC через какой-либо ORM (например, Hibernate)?

Если вы разрабатываете отдельное приложение, лучше сделайте его простым.Для использования ORM или других сред вам не нужен сервер приложений J2EE (и вся сложность, с которой он связан).

Если вам нужно обмениваться огромными объемами данных между БД и приложением,просто забудьте о EJB, сервлетах и ​​веб-службах и просто используйте Hibernate (или напрямую с простым старым JDBC).

Решение для веб-служб на основе REST может быть хорошим, если у вас нет сложных данныхи большие числа (попробуйте указать, сколько времени потребуется, чтобы фактически демаршалировать сообщения SOAP назад и объектам java).