Как эффективно использовать ibatis в сервис-ориентированной архитектуре?

Question

У нас есть несколько сервисов, каждый из которых в идеале должен работать независимо друг от друга.Основное использование сервисов - поддержка нашего веб-приложения.Мы ищем лучший способ использовать ibatis с этими сервисами.

Наш первый подход состоял в том, чтобы иметь один проект с SqlSessionFactory, и чтобы все реализации служб использовали этот проект для доступа к данным.Это означает, что проект зависит от всех сервисов (мы должны были отделить сервис и подразумевать устранение зависимости от окружности) для объектов данных и содержит все карты SQL.Преимуществом будет один экземпляр SqlSessionFactory в любое время и одна конфигурация для управления.Хотя, если один сервис используется, например, для junits или какой-либо другой утилиты, все карты sql загружаются независимо, и все сервисы являются зависимыми.

Другой подход заключается в том, чтобы у каждого сервиса был свой собственный конфигурационный файл и экземпляр ibatisSqlSessionFactory.Это позволило бы избежать необходимости в Мекке зависимостей от проекта доступа к данным, но означает несколько экземпляров SqlFactory в веб-приложении.

Мне нравится второй подход, хотя я вижу хорошие и плохие в обоих.

Что бы вы сделали?Что вы добавляете или убираете из моего аргумента?

Пожалуйста, помогите !!!

Answer 1

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

Если вы используете SOA, вы соглашаетесь на более неэффективное использование ресурсов для разделения и изоляции компонентов.

Answer 2

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

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

Answer 3

Если оба решения применимы, возможно, все ваши службы работают на одной и той же JVM. На мой взгляд, вы должны подумать о запуске компонентов в отдельных JVM. Истинная архитектура компонентов служб - это та, в которой у вас есть несколько компонентов (например, EJB), которые работают в кластерной среде и взаимодействуют друг с другом в слабо связанной среде (например, через JMS, или через Webservices или RMI и т. Д.). Каждый компонент независим и может работать на удаленном сервере.

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

В конце концов, вопрос в том, что действительно нужно вашему приложению.