Spring JavaEE与单机版

我正在做一个项目，我们需要构建几个“独立”模块连接到一个数据库。这些模块主要是后台业务流程，所以前端不多。除了一个显示数据并允许基本CRUD功能的web模块之外。为此，我们计划使用以下技术：

• JPA2（使用hibernate jpa实现）
• CDI（使用spring实现）
• JSF2+primefaces（用于我们的web模块）

最初的计划是只为每个模块创建一个jar文件（带有一个main方法），并通过服务包装器将其安装为（windows）服务。对于我们的web模块，我们将使用Glassfish或JBoss来运行它。然而，最近我们想到了JavaEE。我们可以在JavaEE容器中运行所有模块，比如Glassfish或JBoss，而不仅仅是web模块。关于Java EE的一些问题：

我们还可以/应该在spring中使用CDI吗？或者我们应该切换到EJB3

当我们在容器中而不是在独立模块中使用JPA时，会产生什么后果？有什么区别吗

因为我们的大多数模块都与web无关，所以在JavaEE容器中运行它们是否仍然有意义

---

由于以下常见原因，在应用服务器中运行而不是在独立的java程序中运行是有意义的

1） 您可以将CDI与spring一起使用，因为EJB3也基于类似的概念。 2） 就JPA而言没有区别，只是如果您以后需要向应用程序添加更多的卷，可以通过添加更多运行同一应用程序的机器来添加负载-但是，请注意，这是一个非常重要的工作量，因此这取决于业务需求来做出选择 3） 由于内置的安全性、可靠性、管理和可扩展性，应用服务器胜过独立的java应用程序

如果所有模块（批处理+实时）都与一个产品相关，那么将它们捆绑在一起是一个很好的方法。这是我的建议

将所有模块捆绑到一个ear中

使用JavaEE6并摆脱spring。CDI旨在用于JavaEE中。对于批处理类型的操作，请尝试利用或MDB

对你具体问题的回答

• 我们还可以/应该在spring中使用CDI吗？或者我们应该切换到EJB3

CDI也可以在没有EJB的情况下使用。无论如何，摆脱spring，因为我看不到您的简单项目有任何附加值

• 当我们在容器中而不是在独立模块中使用JPA时，会产生什么后果？有什么区别吗

除了可以从JNDI获取数据源这一事实之外，没有什么区别

• 因为我们的大多数模块都与web无关，所以在JavaEE容器中运行它们是否仍然有意义

---

是的，将单个产品的批处理和实时方面捆绑在一起是有意义的，只要您没有看到任何性能问题。

其他人已经指出了一些优点，因此，如果您将后台进程部署到与web应用程序相同的jvm中，这里有一些缺点

• 启动和停止运行web模块的服务器意味着启动和停止后台进程，这对您来说可能是问题，也可能不是问题
• 如果后台进程占用大量内存或cpu，则可能会影响您的web应用程序，或者如果web应用程序占用大量资源，则可能会影响后台进程，您将与所有三个应用程序共享堆
• web应用可能需要以可通过internet访问的方式部署，但后台进程可能很乐意在没有任何网络访问的情况下运行。那么，如果不需要，为什么要将后台进程公开到internet上呢
• 升级应用程序服务器、框架或配置时，需要测试三件事，如果后台进程独立运行，则可以在web应用程序的单独发布周期中升级它们
• 在容器外开发和测试代码更简单。在容器内运行后台进程意味着后台进程的开发环境更加复杂，您必须等待服务器启动，根据容器内资源启动，然后必须模拟表单单元测试。。。等等

JPA在容器内部和外部是相同的。唯一的区别是如何获得EntityManager，可以使用Spring将其配置为容器内外相同。CDI应该可以在容器外部运行

主要的区别在于如何使用db进行事务处理，例如使用Spring事务与ejb事务

更新： 在评论中回答您的问题：在JPA中，EntityManager不是线程安全的，因此在JavaEE服务器中，每个线程的每个持久化单元将有一个实体管理器。实体管理器的创建和关闭由应用服务器为您管理。每个实体管理器中都有一个缓存。可以配置跨多个实体管理器的二级缓存。在容器外运行时，您必须自己管理JPA实体管理器的数量，这将取决于后台进程中的线程数量和您希望拥有的事务边界。如果你看一本名为“projpa2”的书，其中有一节讨论了在容器内部或外部运行的细节

在我的应用程序中，我没有后台进程，但每个需要实体管理器的类都使用

@PersistenceContext EntityManager em注入实体管理器和spring负责使其在容器内外工作。Spring3.1有一个名为profiles的特性，它使得在容器内部和外部运行相同的代码而不更改一行代码变得非常简单。我不是