我们有几个服务，理想情况下，每个服务都应该相互独立运行。这些服务的主要用途是支持我们的网络应用程序。我们正在寻找将 ibatis 与这些服务一起使用的最佳方式。
我们的第一种方法是创建一个带有 SqlSessionFactory 的项目，并让所有服务实现都使用该项目进行数据访问。这意味着项目依赖于数据对象的所有服务（我们必须分离服务和实现以消除循环依赖），并且它包含所有 sql 映射。优点是随时都有一个 SqlSessionFactory 实例，以及一个要管理的配置。尽管如果将一项服务用于 junits 或其他一些实用程序，则无论如何都会加载所有 sql 映射，并且所有服务都是依赖项。
另一种方法是让每个服务都有自己的 ibatis 配置和 SqlSessionFactory 实例。这将避免对数据访问项目的依赖麦加的需要，但意味着 webapp 上有多个 SqlFactory 实例。
我喜欢第二种方法，尽管我认为这两种方法都有好有坏。
你会怎么办？您从我的论点中添加或删除了什么？
请帮忙！！！
尽管我认为您的第一个论点的优势指向了 SOA 的总体弱点，但我认为如果您正在执行 SOA，那么使所有服务相互依赖就违背了整个目的。
如果您正在执行 SOA，那么您将接受为了组件的解耦和隔离而牺牲资源使用效率更低的代价。
老实说，在您发现性能瓶颈或应用程序变得太大之前，请保持简单。也就是说，除非您希望服务按照自己的时间表独立更新。
在我工作的地方，所有应用程序都共享通用代码。这一切都来自同一个来源，但独立地内置在每个应用程序中。这可能不是最好的解决方案，但至少它可以轻松修改通用代码，而不必担心部署单独的应用程序。它允许随着更多应用程序的引入而更改通用代码，而不会影响以前部署的应用程序。
如果这两种解决方案都适用，那么您的所有服务可能都在同一个 JVM 上运行。在我看来，您应该考虑在单独的 JVM 中运行组件。真正的服务组件架构是您有多个组件（例如 EJB）在集群环境中运行并以松散耦合的人工方式（例如通过 JMS，或 Web 服务或 RMI 等）相互通信的架构。每个组件都是独立的，并且可能在远程服务器中运行。
在这种情况下，我当然会使用第二种方法。但是，如果您的应用程序不需要这种解耦，您应该使用第一种方法，因为它更节省内存。
毕竟，这是您的应用程序真正需要什么的问题。