如何在面向服务的架构中高效地使用ibatis？
我们有多项服务，理想情况下每项服务都应该彼此独立运行。这些服务的主要用途是支持我们的网络应用程序。我们正在寻找将 ibatis 与这些服务结合使用的最佳方式。
我们的第一种方法是使用 SqlSessionFactory 建立一个项目，并让所有服务实现都使用该项目进行数据访问。这意味着该项目依赖于数据对象的所有服务（我们必须将服务和 impl 分开以消除循环依赖），并且它包含所有 sql 映射。优点是任何时候都有一个 SqlSessionFactory 实例，并且需要管理一个配置。尽管如果像 junits 或其他实用程序一样使用一项服务，则无论如何都会加载所有 sql 映射，并且所有服务都是依赖项。
另一种方法是让每个服务都有自己的 ibatis 配置和 SqlSessionFactory 实例。这将避免对数据访问项目的依赖，但意味着 Web 应用程序上有多个 SqlFactory 实例。
我喜欢第二种方法，尽管我认为这两种方法都有好有坏。
你会怎么办？你从我的论点中添加或删除了什么？
请帮助！
We have several services, each of which should ideally operate independently of each other. The primary use of the services is to support our webapp. We are searching for the best way to use ibatis with those services.
Our first approach, was to have one project with the SqlSessionFactory and have all service implementations use that project for data access. This means that project depends on all of the services (we had to seperate service and impl to eliminate circle dependency) for the data objects, and it contains all of the sql maps. The advantage would be one instance of SqlSessionFactory anytime, and one config to manage. Though if one service is used like for junits, or some other utility, all sql maps are loaded regardless, and all services are a dependency.
Another approach would be to have each service have it's own ibatis config and instance of SqlSessionFactory. This would avoid the need for the mecca of dependences on the data access project, but means several instances of SqlFactory on the webapp.
I like the second approach, though I see good and bad in both.
What would you do? What you add or take away from my argument?
Please Help!!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
虽然我认为您的第一个论点的优点指出了 SOA 一般的弱点，但我认为如果您正在实施 SOA，那么它就违背了使所有服务相互依赖的整个目的。
如果您正在实施 SOA，则为了组件的解耦和隔离，您将接受更低效的资源使用的权衡。
Although I think that the strength of your first argument points to the weakness of SOA in general, I think that if you are doing SOA, it defeats the whole purpose to then make all of the services interdependent on each other.
If you are doing SOA, you are accepting the tradeoff of more inefficient resource usage for the sake of decoupling and isolation of the components.
老实说，保持简单，直到发现性能瓶颈或应用程序变得太大。也就是说，除非您希望服务按照自己的时间表独立更新。
在我工作的地方，所有应用程序之间共享通用代码。它们都来自同一来源，但独立构建到每个应用程序中。这可能不是最好的解决方案，但至少它可以轻松修改通用代码，而不必担心部署单独的应用程序。随着更多应用程序的引入，它允许更改通用代码，而不会影响之前部署的应用程序。
Honestly, keep it simple until you find a performance bottleneck or your application grows too large. That is, unless you expect services to be independently updated on their own schedules.
Where I work, there is common code that is shared among all applications. It all comes from the same source, but is independently built into each application. This probably isn't the best solution, but at least it makes it easy to modify common code with out worrying about a separate app being deployed. And it allows common code to change as more applications are introduced, with out effecting previously deployed apps.
如果两种解决方案都适用，那么您的所有服务可能都在同一个 JVM 上运行。在我看来，您应该考虑在单独的 JVM 中运行组件。真正的服务组件架构是这样一种架构，其中有多个组件（例如 EJB）在集群环境中运行，并以松散耦合的方式相互通信（例如通过 JMS、Web 服务或 RMI 等）。每个组件都是独立的，并且可能在远程服务器上运行。
在这种情况下，我当然会使用第二种方法。但如果您的应用程序不需要这种解耦，您应该使用第一种方法，因为它的内存效率更高。
毕竟，这是您的应用程序真正需要什么的问题。
If both solutions can apply, you probably have all of your services run on the same JVM. In my opinion, you should think of running the components in separate JVMs. A true Service Component Architecture is one where you have several components (EJBs for instance) that run in a clustered environment and talk to each other in a loosely coupled manned (through JMS for instance, or Webservices or RMI, etc). Each component is independent and possibly runs in a remote server.
In this case, I would use of course the second approach. But if your application doesn't need this decoupling, you should use the first approach, since it's more memory efficient.
It's after all, a question of what your application really needs.