hybris商务套件中的Jalo层和服务层有什么区别?如果有人能够举一个例子,我会很感激。我知道Jalo图层已被弃用,但如果我必须指定在我的平台中使用哪个图层,那么我将在哪里告诉hybris或我将如何告诉hybris使用特定图层?jalo层vs服务层
回答
在过去,持久性和业务逻辑写在Jalo Layer中。引入服务层后,Jalo Layer中的现有业务逻辑即被移至服务层。有了这个,迁移到服务层的第一个目标就是所有Jalo相关的类都不应该包含任何代码。 由于Jalo Layer不再包含业务逻辑,未来公共API将会小得多。它主要包括查询灵活搜索的方法和保存和删除数据的通用方法。此功能已通过适配器服务(如FlexibleSearchService和ModelService)在服务层中提供。在这种情况下,不再鼓励对Jalo图层的任何访问。第二个目标是消除服务层现有类中的所有Jalo访问。
我想,如果你对于这两个相当不错的hybris维基阅读起来也最好:
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项类型,创建的属性不会在0123alojalo类中(因为它驻留在平台中并且只创建一次),而是在您的扩展管理器类中可用,这有点不直观且麻烦。服务层创建它的所有属性模型类只有在分析和合并所有注册的扩展后才能在实际的ProductModel
类中添加该属性。 还有很多不同之处,所以如果你有更具体的问题随时问他们:)
在第一个Hybris版本中,逻辑通过Jalo(雅加达逻辑)层附加到生成的项目类型类,以便更灵活Hybris现在将所有内容都移动到服务层的更灵活的方法(尚未完成,促销是传统Jalo图层的一个很好的例子)。
- 1. 管理层vs服务层
- 2. 服务层和Web API服务层?
- 3. 存储库层VS Web层VS服务器端VS Alfresco的客户端
- 4. 服务层=应用层= GRASP控制层
- 5. spring roo vs appfuse生成服务/ dao层
- 6. 定价层vs服务层与实例大小
- 7. 使用搜索服务器服务层vs数据库层来查找实体
- 8. 从服务层
- 9. Python服务层
- 10. n层业务/服务层设计
- 11. 服务和服务层
- 12. Windows服务与服务层
- 13. 业务层VS的SQL Server
- 14. GUI层vs代码层vs Swing
- 15. 具有n层业务服务器的N层Web服务器
- 16. 业务层与服务层的服务引用
- 17. Asp.Net MVC服务层 - 附加服务vs通过参数
- 18. 服务层建议
- 19. AutoMapper在服务层
- 20. C#,GenericRepository,服务层
- 21. WPF MVVM服务层
- 22. ZF1 Doctrine2服务层
- 23. 又该服务层
- 24. 服务层验证
- 25. 访问服务层
- 26. Asp.Net Mvc服务层
- 27. FluentValidation在服务层?
- 28. 服务层和db层的Spring注解
- 29. MVVM和分层,实现服务层
- 30. 将服务层与验证层分开