哈Ha！ 我们最近出版了德国Java冠军Sebastian Dashner的书“
学习Java EE。大型企业的现代编程 ”。
Dashner先生积极撰写与现代Java EE相关的主题并发表演讲，因此他的博客没有忽略现在由Eclipse开发的Jakarta EE平台的一般设计原则。 我们今天提请您注意此文章（6月）的翻译。
Jakarta EE平台正在逐步接管，随之而来的是企业发展的新规范。 为了就即将出现的各种标准和技术达成共识，只有开发了Jakarta EE规范的通用设计原则，整个Java EE社区才会受益。
我相信Java EE技术仅凭一些原则就取得了如此成功。 下面，我将提出我的观点，即在我看来，Java EE中开发的哪些设计原则最重要，哪些值得进一步研究，并有可能作为Jakarta EE中的设计建议。
我决定写这篇文章，是受德米特里·科尼洛夫（Dmitry Kornilov）关于雅加达EE技术发展的方向的建议的启发。
首先是业务逻辑Java EE中采用的编程模型使开发人员可以完全专注于所需的内容-即业务逻辑。 您不再需要继承API类。 开发人员可以用普通的Java语言表达其主题领域的逻辑，并主要（使用注释）以声明方式控制应用程序服务器的行为。 因此，该框架无缝地集成到您的代码中，并且从本质上讲，从那里删除同样容易。 设计时，不要依赖于重复使用，而是要轻松移除。
但是，实现应最大程度地减轻开发人员的最艰巨的工作-也就是说，使开发人员可以摆脱与业务逻辑无关的技术要求。 示例包括多线程，事务，控制反转或HTTP请求处理。 在应用程序方面，无聊是一件好事:)
在我看来，该框架不仅不干扰业务逻辑的实现，而且还鼓励程序员将已开发的功能快速投入生产，这对我来说很重要。 无需完善框架，将业务逻辑代码带到理想状态是更好的选择。 将现代的Java EE或Spring与老式的J2EE版本进行比较-我想您会立即理解我的意思。
Jakarta EE应该以同样的方式进行开发，因此，应专注于允许开发人员快速实现业务逻辑的规范。
配置约定Java EE最大限度地减少了定义典型企业应用程序所需的配置。 在大多数实际情况下，协议可以直接使用；无需任何配置。 因此，您不再需要任何XML文件来配置简单的Java EE应用程序。 另一个示例是JAX-RS提供与JAX-RS方法的返回值相对应的默认HTTP响应代码。
Java EE确实具有修改行为和实现更复杂的脚本的灵活性。 但是，对此没有达成共识。
Jakarta EE必须继续将简单变成简单，将复杂变成可能。
互操作性规范Jakarta EE应该继续并扩大规范的互操作性。 Java EE符合现有规范及其中提供的功能，这些功能已经成为标准的一部分。
开发人员可以依靠不同的规范来彼此良好地交互，而无需任何配置。 要求标准：如果运行时环境同时支持规范A和规范B，则A + B必须相互交互。 示例：JAX-RS资源类中可以使用组件验证，JAXB或JSON-B，并且不需要进一步的配置。
依赖注入和CDI当然，Jakarta EE不希望重新发明那些已经存在的东西，例如与CDI相关的依赖注入。 希望规范使用并强调JSR 330或（如有必要）CDI的优势。
UriInfo示例是在资源方法中使用JAX-RS中的
UriInfo 。 注释
@Inject尚不支持此类方法的实现。 程序员对通用机制的依赖程度越高，越便于程序员工作。
另一个特定的措施是：必须在规范中提供CDI提供程序，并在必要时为需要创建的类型提供类型安全的限定符。 因此，目前，只能通过
ClientBuilder API以编程方式获取JAX-RS客户端实例。 制造商和限定符通过提供声明性定义来简化程序员的工作。
声明式方法对于所有这些，Java EE API在使用控制反转的同时，严重依赖于声明式方法。 因此，开发人员不会直接调用该功能。 容器负责调用函数，而我们则依赖于代码定义。 示例（根据最新规范）是JAX-RS，JSON-B或CDI。
Jakarta EE不仅提供更全面的软件API，而且应进一步促进声明性定义和控件倒置的使用。
部署策略Java EE的一个独特功能（在我看来是一个很大的优势）是这里提出的部署模型，其中业务逻辑问题与实现无关。 开发人员专用于API的程序，这不是部署工件的一部分，而是由应用程序容器实现的。
这些紧凑的部署工件简化并加快了程序交付，包括组装，发布和部署。 它们还与Docker中使用的容器文件系统级别兼容。 在组装过程中，只需重建或重新提交更改的元素。
理想情况下，部署工件应仅包含业务逻辑，而不包含其他任何内容； 运行时实现和可能添加的第三方库在较低级别提供，例如，在容器组装的前一阶段添加的应用程序服务器库中。
在Jakarta EE中，部署的工件也必须被视为一流的实体。 也许将有机会根据应用程序要求的规范进一步加强运行时环境。 但是，Jakarta EE希望最大程度地关注开发人员的业务逻辑和生产力，并且执行时间的优化已经是次要的。
可测性应用上述原理，尤其是优先考虑声明式编程和依赖项注入，我们正在改善业务代码的可测试性。 因此，开发人员可以直接在测试脚本中实例化对象，因为现在您无需继承API类或调用以前需要模拟的不便功能。
但是，在Jakarta EE中，有必要在代码级别认真完善集成测试的标准化，以使其不依赖于制造商。 以前，这正是与Arquillian合作时必须处理的内容。 在实际项目中，这样的标准将很有用，它允许您仅声明测试部署方案并为一个或多个组件调用功能。 早些时候，我写道，例如在内置容器中运行应用程序时，我不认为在代码级别进行集成测试非常重要。 但是，如果您在代码级别对集成测试进行标准化，则显然会产生积极的效果。
结论我认为Java EE API如此广泛地用于实际项目中并非偶然：这些API经过精心设计和设计，并遵循清晰的原则，因此，不仅可以统一单个规范，而且可以统一整个平台。 它们使您可以一次使用多个规范，并保持同一精神。 在这里，我们设法摆脱了只会使程序员的工作复杂化的人为障碍，因此，我相信，所有企业开发都变得更加愉快。