问在数据库(存储过程)中保留或不保留生命周期的业务逻辑

EN

Liferay在应用程序代码级别(高级)执行其业务逻辑的原因如下：

1. 通过这种方式，门户变得与数据库无关，因此可以在不考虑底层数据库的情况下进行部署。
2. 并非所有数据库都支持存储过程。因此，为了支持多个数据库，代码不能存储在Procedure.
3. Portals中，它们大多是内容驱动的，数据密集度不是很高。

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

所以现在的问题是你能不能使用它？

？

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

建议不要直接从存储过程中使用Liferay的数据库表，因为Liferay可能会更改较新版本的数据库体系结构。因此它可能会使您的升级过程复杂化。

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

1. Arguments for/against Business Logic in stored procedures.在这篇direction.
2. Whether to put the business logic in Stored Procedure or Not?
3. Code generators vs. ORMs vs. Stored Procedures.

中，前几个答案是很好的指针

在这种情况下，如果

在这种情况下没有增加太多价值，那么有一种方法可以绕过hibernate。

如果它没有增加价值，那么是的，您可以使用JDBC作为您自己的自定义portlet，而不使用hibernate。使用JDBC没有什么特别的配置，它和:-)一样好用。

希望这能将你引向一个积极的方向。

Liferay在应用程序代码中执行其业务逻辑并不意味着您必须这样做，您的应用程序的架构完全取决于您。

(这假设您的应用程序数据没有引用Liferay的数据)