Jalo 层与服务层

Posted 2023-02-16

【中文标题】Jalo 层与服务层

【英文标题】：Jalo Layer vs Service Layer

【发布时间】：2016-05-04 12:00:21

【问题描述】：

Hybris 商务套件中的Jalo 层 和服务层 有什么区别？如果有人能举个例子，我将不胜感激。我知道 Jalo 层已被弃用，但如果我必须指定在我的平台中使用哪个层，那么我将在哪里告诉 Hybris 或者我将如何告诉 Hybris 使用特定层？

【参考方案1】：

过去，持久性和业务逻辑是在 Jalo 层中编写的。在引入服务层之后，Jalo 层中现有的业务逻辑正在被移动到服务层。有了这个，迁移到服务层的第一个目标是所有与 Jalo 相关的类都不应包含任何代码。 由于 Jalo 层不应再包含业务逻辑，因此公共 API 将来会更小。它将主要包括查询灵活搜索的方法和保存和删除数据的通用方法。此功能已在服务层中由适配器服务（如 FlexibleSearchService 和 ModelService）提供。在这种情况下，不再鼓励对 Jalo 层的任何访问。第二个目标是消除服务层现有类中的所有 Jalo 访问。

来源： 访问https://wiki.hybris.com/pages/viewpage.action?spaceKey=release5&title=Transitioning+to+the+ServiceLayer

【参考方案2】：

我认为最好阅读关于两者的相当不错的 hybris wiki：

贾洛：https://wiki.hybris.com/display/release5/Jalo+Layer

服务层：https://wiki.hybris.com/display/release5/ServiceLayer

你不必指定你使用哪一个（它们都一直在运行），如果你开始一个新项目，你基本上必须（或者至少真的应该！）只使用服务层，因为 Jalo 将消失（所以他们说至少在相当长的一段时间内）在下一个主要版本之一中。 简而言之，Jalo 是旧的持久性机制，而引入服务层是为了解决 jalo 层存在的各种问题（性能/缓存、可扩展性等）。

因此，如果您将只/主要从事新项目，您可能不必获得太多关于 jalo 层的知识，但如果您计划成为 hybris 顾问或处理旧的遗留 hybris 代码，您将拥有更多地与 Jalo 打交道。

一个小例子： 在您的 items.xml 文件（在其中声明数据模型）中，您可以指定 jaloclass 属性，同时使平台为您创建 Java 类。 例如：core-items.xml 有 Product 声明为 jaloclass="de.hybris.platform.jalo.product.Product"。 该平台还会自动创建相应的服务层类（始终称为*Model.java，例如de.hybris.platform.core.model.product.ProductModel。 jalo 层的一个限制是，例如如果您想使用某个属性在您自己的扩展之一中扩展 Product 项目类型，则新创建的属性将不在 Product jalo 类中（因为它驻留在平台中并且只创建一次），而是它将在您的扩展管理器类中可用，这有点不直观和麻烦。服务层仅在分析和合并所有已注册的扩展后才创建其所有模型类，因此能够在实际的ProductModel 类中添加该属性。 还有很多不同之处，所以如果您有更具体的问题，请随时提出:)

【参考方案3】：

在第一个 Hybris 版本中，Logic 被附加到通过 Jalo（Jakarta Logic）层生成的项目类型类，为了更加灵活，Hybris 现在正在将所有内容转移到更灵活的服务层方法（尚未完成，促销是遗留 Jalo 层的一个很好的例子）。

【参考方案4】：

根据阅读上述答案并根据第一个答案做了一次练习，我的结论如下：

是的，JALO 的非抽象类实现已作为 *Model.java 移动，用于编写更具体的业务逻辑，包括前 2 个答案中的良好解释。

干杯，