【问题标题】:Keeping Business logic for liferay in Database (Stored Procedures) or not to keep在数据库(存储过程)中保留 Liferay 的业务逻辑或不保留
【发布时间】:2012-08-06 17:49:13
【问题描述】:

我们的应用程序有非常大的数据,我们想要执行我们的业务逻辑(聚合) 在数据库层(存储过程)中。

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

如果我们想为业务逻辑使用存储过程会有什么影响?

由于 Liferay 也使用 Hibernate,如果在这种情况下没有增加太多价值,有没有办法在这种情况下绕过休眠?

【问题讨论】:

    标签: hibernate liferay portlet liferay-6


    【解决方案1】:

    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

    如果在这种情况下没有增加太多价值,有没有办法在这种情况下绕过休眠。

    如果它没有增加价值,那么是的,您可以将 JDBC 用于您自己的自定义 portlet 绕过休眠。使用 JDBC 没有什么特别的配置,它是同样的好东西 :-)

    希望这会引导您朝着积极的方向前进。

    【讨论】:

      【解决方案2】:

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

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

      【讨论】:

        猜你喜欢
        • 2013-04-01
        • 2013-10-19
        • 2013-05-24
        • 1970-01-01
        • 2011-05-28
        • 2010-10-21
        • 2019-08-10
        • 1970-01-01
        • 2011-09-23
        相关资源
        最近更新 更多