Hybris商务套件中 Jalo图层与服务图层之间的区别是什么？如果有人可以举一个例子，我将非常感激。我知道Jalo图层已被弃用，但如果我必须指定在我的平台中使用哪个图层，那么我将在哪里告诉Hybris或者我将如何告诉Hybris使用特定图层？
答案 0 :(得分：10)
我认为最好是阅读有关两者的相当不错的hybris wiki：
Jalo：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类中添加该属性。
还有很多不同之处，所以如果你有更具体的问题，请随时问他们：）
答案 1 :(得分：3)
过去，持久性和业务逻辑是在Jalo Layer中编写的。在引入服务层之后，Jalo Layer中的现有业务逻辑将被移动到服务层。有了这个，迁移到服务层的第一个目标是所有与Jalo相关的类都不应包含任何代码。 由于Jalo Layer不再包含业务逻辑，因此将来公共API将会小得多。它主要包括查询灵活搜索的方法和保存和删除数据的通用方法。服务层已经通过FlexibleSearchService和ModelService等适配器服务提供了此功能。在这种情况下，不再鼓励对Jalo Layer的任何访问。第二个目标是消除现有服务层类中的所有Jalo访问。
答案 2 :(得分：1)
在阅读完上述答案后，根据第一个答案做了一个练习，我的结论如下：
是的，JALO的非抽象类实现已作为* Model.java移动，用于编写更具体的业务逻辑，包括前两个答案中的很好的解释。
干杯
答案 3 :(得分：0)
在第一个Hybris版本中，Logic通过Jalo（Jakarta Logic）层附加到生成的项目类型类，以便更灵活Hybris现在将所有内容转移到更灵活的服务层方法（尚未完成，促销）是传统Jalo层的一个很好的例子。）