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

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

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

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

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

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

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


java mybatis soa ibatis
person Andy    schedule 05.11.2010    source источник
comment
Спасибо за отличные ответы, парень, я ценю все ответы. Мне очень сложно выбрать лучший.   -  person Andy    schedule 12.11.2010

Ответы (3)


arrow_upward
2
arrow_downward

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

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

person Yishai    schedule 05.11.2010

arrow_upward
1
arrow_downward

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

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

person Jeremy    schedule 05.11.2010

arrow_upward
0
arrow_downward

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

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

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

person Paul Ianas    schedule 12.11.2010
comment
Спасибо за ваш ответ, я пытаюсь выбрать лучший путь, который не обеспечит то, что нужно нашему приложению сейчас, но также будет готов к тому, что может произойти в будущем. Спасибо! - person Andy; 12.11.2010