相关内容

开发人员和架构师通常将对象模型设计为主要数据源，将数据库模式作为模型的产物，并且高度依赖ORM来管理这些。这往往导致关系型数据库中的数据表示非常低效，从而引发性能问题，因为关系数据库中的数学与编程语言对象中的数学有很大不同。这些错误通常很难修复，而且成本很高，尤其是当数据库模式已经投入生产时。

尽管ORM现在是一个非常智能的工具，但它仍然不是人工智能（还不是）。因此，为了处理这些问题，我相信每个企业或全栈开发人员都应该在数据库及其编程语言如何与其交互的教育上投入更多时间。良好的持久层设计可以解决大多数性能问题，甚至可以完全防止它们发生。

是的，绝对如此。尽管我们尽可能使用标准的JPA，但在我们的最终客户部署中，我们也对Hibernate进行了特定的优化，比如如果我们使用Hibernate 5，我们会进行预构建代码的仪器化。在我之前的一个项目中，我们使用了一些二级缓存，Hibernate集成得几乎无缝。

Java EE最近一直是许多讨论的主题。许多甚至致命的预测都被提出来了，但我个人认为Java EE仍然会存在，并取得重大进展。有大量的公司和企业在使用Java EE技术构建业务，由于EE是一个经过验证的标准，它们不会很快消失。

实际上，这是Java EE的主要优势——它是一个标准。这意味着它是一个保证的、可靠的、经过测试的功能集合，它在所有支持的平台上的行为和结果都是相同的。而且，标准不是随意指定的，标准是根据当前技术的最佳和最有价值的内容建立的。而建立这些技术的最常见方式来自于社区。

社区努力的一个好例子就是Microprofile倡议，该倡议由独立的Java EE服务器供应商推动。由于微服务现在非常流行，活动家们试图为Java EE上这种架构的最佳利用创造一个真正通用的解决方案。

尽管关于应该包含在这个配置文件中的内容有一些争议，但已经有了一个起点。讨论是开放的，每个人都欢迎贡献力量。实际上，看到标准是如何产生的非常有趣！他们正在做得很出色！另一个例子是Java EE Guardians，他们在Java EE的各个方面都做出了巨大的贡献！

至于云计算，Oracle承诺将更多地努力实现更好的Java EE云集成。但就我们目前的环境而言，我们有PaaS和IaaS解决方案的混合体。例如，一些服务器被Docker化或打包成可执行jar文件，在云中某处运行，数据库作为服务提供。但我们在那里遇到了一些延迟问题。

我现在正在等待Entity Graph功能的全额支持。我本人认为这是一种非常实用的方式，可以很好地控制你获取的内容，并能够带来一些真正优秀的性能提升，特别是在已经投入生产的系统中。