1

具体来说，EIS（数据库）层与使用带有 POJO 和轻框架的 Web 层或使用 EJB 的标准业务逻辑层。此外，除了这些我不知道的选项之外，可能还有其他选项。基本上，它是对有和没有 EJB 的业务逻辑的设计考虑。使用一种替代方法而不是另一种方法的指南。

这将是在应用服务器上部署的 Java EE 应用程序的上下文中。

我的印象是，应该有一些关于如何在应用程序中构建它的基本准则，并且不能总是一个接一个，例如出于性能原因使用数据库或始终使用 EJB，因为我使用的应用程序已经使用了所有这三种结构。我只是从未想过在做出决定时应该使用什么设计指南？

我的思路是：

  • 如果您有包含数百万行的数据库表，请考虑将业务逻辑放入存储过程和触发器中。
  • 如果您有一个应用程序的简单业务逻辑，请考虑使用 POJO 的业务逻辑。
4

2 回答 2

1

我会尝试做以下问题：

  • 对高性能有要求吗？
  • 什么是基础设施？一台服务器？簇？云 ？
  • 我的记忆力有限吗？
  • 应用程序将使用/管理数千条、数百万条或数十亿条记录？
  • 它会活多久？5年，20年？
  • 应用程序有多大，有多少开发人员将致力于它？
  • 开发人员是否熟悉该技术（即框架）？

我认为对于有多个开发人员同时工作并且计划长时间运行的大型应用程序，使用 WEB/EJB/JPA 架构是一个很大的优势，它生成的代码高度可维护且非常易于阅读。但是，如果应用程序要处理数百万条记录，那么在性能更好的技术/框架中思考可能会更好。

于 2013-08-13T21:28:49.547 回答
1

解决此类问题的最佳方法不止一种。这取决于您的应用程序的属性/要求。这里有一些提示：

如果您有有趣的领域逻辑，请考虑在您的实体中使用具有丰富关系和行为的 JPA（领域模型——参见领域驱动设计）。长期以来，这一直是我的首选方式。

如果您的应用程序是一个简单的 CRUD 应用程序（没有大量深域逻辑的数据维护），您可能无需 JPA（但为了方便起见，我个人仍会使用它），以及完成基本功能的最简单方法. 最小的业务逻辑可以在服务层的“事务脚本”中实现。

如果您必须跨数据库中的许多 row 进行操作，并且运行时至关重要，那么请考虑存储过程。对我来说，这是最后的手段，因为缺乏易测试性和维护/变更控制。但是，在真正需要时，没有更好的方法来获得巨大的性能优势。

IMO，您可以混合搭配上述内容。但我是一个实用主义者而不是纯粹主义者。

要记住的一件事是业务逻辑存在于系统中的“下层”，它的可重用性越高。这就是我喜欢 DDD 方法的原因之一。但它并不适用于所有情况。

于 2013-10-02T04:03:16.860 回答