保持业务逻辑在数据库（存储过程）中的生命周期或不保留

Question

我们的应用程序包含非常大的数据，我们希望执行业务逻辑（聚合） 在数据库层（存储过程）中。

Liferay更喜欢在业务层中拥有业务逻辑（具有多层架构）。

如果我们想使用商业逻辑存储过程会产生什么影响？

由于Liferay也使用Hibernate，如果在这种情况下没有增加太多值，有没有办法绕过hibernate？

Answer 1

Liferay在应用程序代码中执行其业务逻辑这一事实并不意味着您必须执行相同的操作，应用程序的体系结构完全取决于您。

（这假设您的应用程序数据未引用Liferay的数据）

Answer 2

有理由说Liferay在应用程序代码级别（高级别）执行其业务逻辑：

1. 这样门户就变得与数据库无关，因此可以在不考虑底层数据库的情况下进行部署。
2. 并非所有数据库都支持存储过程。因此，为了支持多个数据库，代码不能存储在存储过程中。
3. 门户网站主要是内容驱动的，而不是数据密集型。

可能还有其他原因，或者他们可能会遵循其他一些理念，但这是我现在能想到的。

  

现在问题是否可以使用它？

正如frant.hartm所说，这完全取决于你。这取决于您的要求以及您计划如何设计，维护和增强您的架构。

另外请注意：建议不要直接从存储过程中使用Liferay的数据库表，因为Liferay可能会更新较新版本的数据库架构。因此，它可能会使升级过程复杂化。

我觉得这个问题与liferay不相关，因此这里有一些链接可能会帮助你做出决定：

1. Arguments for/against Business Logic in stored procedures。前几个答案是朝着这个方向发展的好方法。
2. Whether to put the business logic in Stored Procedure or Not?
3. Code generators vs. ORMs vs. Stored Procedures。

  

如果在这种情况下没有添加太多值，是否有办法通过hibernate。

如果它没有增加值，那么你可以通过hibernate将JDBC用于你自己的自定义portlet。使用JDBC没有什么特别的配置，它是一个很好的旧东西： - ）。

希望这能带领你走向积极的方向。