Java社区中有很多关于Spring vs Java EE的话题。 一群人会争辩说您应该使用一个而不是其他。等等。当我看到这一点时，我不禁要想为什么我们不能同时使用它们呢？ 实际上，我认为有效地使用它们会为构建基础架构创建一个伟大的技术堆栈，例如对于一家大型公司而言，该公司希望提供一个可以托管和运行许多不同应用程序和项目的通用平台。

为什么将Spring和Java EE结合在一起？

在编写软件时，我们创建和构建可重复使用的库/框架，并帮助我们更快地完成工作。 Spring是一个像瑞士军刀一样的库，它允许以一种非侵入性的方式构建应用程序，并具有许多更简单的包装器和帮助器类。 这就是我所说的“对开发人员友好”的库。

但是，许多人没有意识到Spring只是一个包含对许多可以简化开发工作的包装器的库。 例如，Spring具有一个Web框架层，可让您编写MVC Web应用程序，但是您仍然需要Servlet容器（服务器）。 Spring提供的数据层主要包装了其他JPA / Hibernate / JDBC，这些JPA / Hibernate / JDBC很好地集成在了它们的IoC容器中，但是实际的ORM实现不在Spring之外（例如：Hibernate）。 Spring包装了JMS甚至JNDI进行开发，但是您仍然需要JMS服务器或JNDI提供程序。 Spring具有事务管理器抽象层，但它只是一个包装器（对于单个数据库，实际上是数据库供应商提供了交易保证的ACID属性，而不是Spring）。 如果要在多个资源（例如JMS和数据库，或多个数据库）上进行原子事务，则仍然需要“真实”事务管理器（JTA）！

所以现在您看到，要构建成功的企业应用程序，您需要在许多供应商提供的功能之上使用Spring。 如果您不小心，可能会陷入难以集成和部署的许多专有服务中。 这就是Java EE的用武之地。这是规范布局，供应商必须以标准方式提供大多数这些服务。 因此，任何JEE法规遵从性服务器都将提供带有标准API的服务，该标准API应该以类似的方式工作。

现在必须保持平衡。 根据我的经验，您执行的标准越多，获得的“对开发人员友好的”就越少。 但是，与此同时，如果没有标准，则很难提供通用的基础结构，例如API，运行时服务器甚至OS环境进行部署。 这就是为什么我认为将Spring与Java EE相结合将为IT社区带来一个更实用和有效的平台的原因。

选择技术栈

并非每个项目的创建都是平等的，他们的需求在很大程度上不同。 因此，不可能提供一个满足所有项目需求的通用技术堆栈。 但是我们当然可以尝试创建一个可以满足大多数项目需求的通用工具。 另外，选择一个具体的库/堆栈是非常有根据的，无论选择哪种实际实现，总是会有利弊的。 考虑到这一点，我将尝试提出自己对技术栈的个人选择，我认为它将为承载各种项目和应用程序提供最灵活的平台。 特别是在大型公司环境中。

我将选择Java EE应用程序服务器作为通用平台。 从中，我将选择一些“对开发人员友好”的库来替换（或在顶部添加）一些现有的EE标准，以提高生产率。 我认为EE已经走了很长一段路，并且在每次规范迭代中都变得更好，但是我仍然觉得将POJO服务连接在一起时，使用Spring作为IoC容器比使用CDI有更大的灵活性。 另外，Spring框架带有非常灵活的MVC层，与普通的Servlet API相比，该层有效且易于开发。

使用Java EE 6，服务器必须提供两个配置文件。 因此，让我们从这两个视图开始探索堆栈。

JEE Web配置文件–基于Web的更轻便的应用程序

• 使用Spring MVC（控制器，表单，验证，ModelAndView和IoC配置）代替普通的Servlet API编程。
• 使用尽可能多的POJO编写后端业务服务逻辑，并使用Spring IoC进行连接。 不要滥用这个。 我个人认为，与CDI相比，Spring IoC更灵活，更易于使用。
• 将JPA用于数据服务层而不是JDBC API编程。
• 使用JSON数据交换格式。 根据经验，与XML相比，JSON更加高效且易于使用。
• 视图选项：
  • 使用格式正确的xhtml / Bootstraps / jquery / AJAX->如果您只需要静态页面和一些客户端交互
• Servlet 3.0现在支持异步请求。 这解决了Web域中的许多难题。 如果需要，可以利用它！ （最新的Spring MVC已经对此提供支持。）

JEE 6完整个人资料–完整EE功能应用程序

• 在Web配置文件中上述所有内容之上。
• 将JMS用于属于点对点或发布/订阅域的任何消息传递需求。
• 当您需要原子事务进行多个数据库和/或JMS交付时，请使用JTA。
• 使用标准的JAX-RS（RESTful Web服务API）公开外部服务。 使用JSON数据交换格式。
• 使用一致的Spring IoC进行服务注入。 与CDI相比，它更灵活，更易于使用。
• 如果可能的话，使用POJO服务并通过Spring代替EJB进行连接。 我发现它们更易于测试和开发。
• 加上它所支持的其他任何EE规范，例如（JavaMail和JCA等。通常，Spring也会为这些API提供更简单的包装。）

Apache Camel –轻量级ESB

Camel项目不是EE标准。 但是，我的经验是，使用简单的骆驼路线/工作流程可以轻松完成许多常见的IT工作。 Camel的开发和样式易于理解且易于测试。 它可以作为独立的应用程序/服务运行，也可以作为Web应用程序的一部分运行。 我相信，在上面的通用平台之上添加一个巨大的价值。 您将在需要以下各项时使用它：

• 对于任何类似工作流流程的集成模式（例如：将文件轮询器桥接到Web服务，将JMS队列桥接到数据库等）
• 用于创建业务工作流程。
• 适用于任何ETL工作流程。
• 为了轻松将业务需求工作流映射到代码逻辑流程

使用哪个EE应用程序服务器

我认为这也是主观的，但是我们需要选择适合我们业务需求的产品。 我个人更喜欢JBoss，因为它是开源的，但是他们提供了其应用服务器的商业支持版本。 作为基于开源的产品，它使开发人员在学习和探索平台方面具有更大的灵活性。 我也看到了他们内部项目的许多好处，例如开放的测试工具和库，这些都使平台开发人员受益。

Tomcat服务器呢？

Tomcat是一个非常著名的Servlet容器。 但是，它只是一个支持Servlet / JSP应用程序的Web容器。 它不提供Java EE服务器提供的JMS或JTA功能。 事实上，仅使用一个简单的Tomcat服务器就可以满足许多Web应用程序的需求。 但是，在大型IT环境中，您经常需要仅由Java EE服务器提供的其他服务。 在许多情况下，人们将只需要运行Tomcat webapp并在需要时桥接到其他Java EE服务器。

使用JEE6，可以将Web配置文件简化为大多数Web容器功能，这应该使服务器启动更快（加载更少的额外服务）。 但是，如果应用程序需要额外的EE功能，我们提供的平台将能够支持它们。

翻译自: https://www.javacodegeeks.com/2013/06/choosing-technology-stack-to-build-a-common-platform.html