最近工作重点转移到了SAP Commerce上来，正好有机会把该产品里由Java实现的订单处理框架和我之前长期工作过的，ABAP实现的SAP CRM One Order框架做个比较：基于Spring的Bean替换机制 vs ABAP函数+配置表，两种方式都实现了强大的可扩展性。
SAP Commerce的订单处理框架把订单处理业务按照步骤拆分成一个个细粒度的处理单元，封装到一个个Spring Bean里。模型和其行为之间通过策略模式(Strategy Design Pattern)进行松耦合式的关联。Commerce二次开发人员可以灵活地将定制业务逻辑实现在自开发的Bean里，并将其通过Spring框架注入到Commerce的订单处理框架中，实现订单处理业务的定制效果。
而SAP CRM One Order里一系列维护在配置表里的函数，学习了SAP Commerce之后，我倾向于把它们类比为比SAP Commerce Order Bean更细粒度的处理单元。SAP Commerce里能够注入的Order处理逻辑的粒度是一个端到端的操作，比如SubmitOrderStrategy，CloneAbstractOrderStrategy，CreateOrderFromCartStrategy, SaveAbstractOrderStrategy, 一个Bean就能实现一个端到端的Order操作；而SAP CRM One Order框架配置表里可以灵活配置的ABAP函数，往往需要多个函数组合在一起协同工作才能完成一个上述操作。虽然可配置和替换的粒度不同，但都殊途同归：在不修改SAP标准代码的前提下，给二次开发人员提供一种灵活的增强机制(Extensibility).
要获取更多Jerry的原创文章，请关注公众号"汪子熙":
网友评论