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的原创文章，尽在：”汪子熙”:
