Accelerator是Spartacus公布之前,SAP Commerce Cloud应用的Storefront实现。Accelerator是一个开箱即用的web实现模板,是Commerce平台的一部分,以源代码的形式交付给客户。客户通过一个叫做module generator的工具,基于Accelerator 模板代码生成本人的Storefront实现。Accelerator这种同Commerce平台的紧耦合关系,以及基于源代码级别的二次开发形式,给Commerce我的项目施行的可降级性带来很大的挑战。例如,当客户发现新版本的Accelerator能满足本人新的业务需要时,心愿降级Accelerator. 然而因为Accelerator是Commerce平台的一部分,所以必须先降级整个Commerce,再应用module generator基于高版本的Accelerator代码生成自定义实现,再把基于低版本Accelerator模板而进行的二次开发,逐个手动迁徙到高版本Accelerator生成的自定义实现中去。当Commerce的二次开发达到肯定规模量时,这种手动降级的形式很挑战。
Accelerator具备的这些缺点,在Spartacus问世之后都迎刃而解。
Accelerator通过源代码的形式提供了一个Storefront的开发模板,而Spartacus则以库的形式,提供了一个轻型的Storefront开发框架。咱们新建一个Angular利用,导入对Spartacus库的依赖,当咱们须要降级Spartacus时,只须要更新Angular利用的package.json里Spartacus库文件的版本号即可,因而从Spartacus从可降级性上来说是一个微小的飞跃。
Spartacus采纳API的形式同Commerce交互,这使得Spartacus能够同Commerce离开部署,别离进行降级,比方目前曾经公布的Spartacus 3.0,反对从Commerce 1808开始及其之后的所有版本。
Spartacus采纳Angular开发,编译之后生成JavaScript作为其运行时语言,这样一来,应用Spartacus的二次开发人员,不再须要过来开发Accelerator那样具备前端JSP和后端Java的全栈开发技术栈。
Accelerator的可扩展性,是通过就义可降级性为代价换来的。同Accelerator只有源代码级别的批改这一繁多的扩大形式相比,Spartacus实现扩展性的伎俩更加多元化
。
(1) Spartacus的模块之一,ConfigModule,将业务逻辑和页面布局以及款式,通过配置的形式裸露进去,二次开发人员通过调整配置,能够更改Spartacus默认的行为和页面布局以及款式。
(2) Spartacus的页面布局由不同的Angular Component组成,这些Angular Component同Commerce的CMS Component具备一一对应关系。Spartacus容许二次开发人员加强甚至开发新的Angular Component,去替换Spartacus公布时应用的默认Component,以次来实现客户的页面定制化需要。
(3) 借助Angular弱小的依赖注入机制,Spartacus容许开发人员像Commerce后盾开发人员应用Java Spring框架那样,开发本人的service实现,通过Angular的Dependency Injection机制,注入自开发的service,从而达到定制化Spartacus的运行流程和逻辑的需要。
更多Jerry的原创文章,尽在:”汪子熙”: