具体来说，EIS(数据库)层与使用带有 POJO 和轻量级框架的 Web 层或使用 EJB 的标准业务逻辑层进行比较。此外，除了这些之外，可能还有其他我不知道的选择。基本上，它是带或不带 EJB 的业务逻辑的设计考虑因素。使用一种替代方案而不是另一种替代方案的指南。
这将是在应用服务器上部署的 Java EE 应用程序的上下文中。
我的印象是，应该有一些关于如何在应用程序中构建它的基本准则，并且它不能总是一个比另一个，例如出于性能原因使用数据库或始终使用 EJB，因为我工作过以及使用所有这三种结构的应用程序。我只是从来没有想过我应该使用什么设计准则来做出决定？
我的想法是:
- 如果您的数据库表包含数百万行，请考虑将业务逻辑放入存储过程和触发器中。
- 如果您的应用程序有简单的业务逻辑，请考虑使用 POJO 来实现业务逻辑。
最佳答案
我会尝试做以下问题:
- 是否有高性能要求？
- 基础设施是什么？一台服务器？簇？云？
- 我的内存力有限吗？
- 应用程序将使用/管理数千条、数百万条或数十亿条记录？
- 它会持续多久？ 5年，20年？
- 该应用程序有多大，有多少开发人员将参与其中？
- 开发人员是否熟悉该技术(即框架)？
我认为对于多个开发人员同时工作并且计划运行很长一段时间的大型应用程序，使用 WEB/EJB/JPA 架构是一个很大的优势，它生成的代码高度可维护并且非常容易读。但是，如果应用程序要处理数百万条记录，可能最好考虑具有更好性能的技术/框架。
关于java - 在确定将业务逻辑放置在 Java EE 应用程序中的何处时，需要考虑哪些设计考虑问题？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18216521/