Hybris平台Web架构模式演变：前后端分离

“前后端分离”显然已不是什么新鲜的话题，表面上看是一场架构模式的变革，但实质上是为了解决以往传统的服务端MVC设计模式的一些诟病和痛点。前后端分离带来的全新的前后端协作方式能够让专业的人做专业的事，无论前端后端都能更专注在自己擅长的方面。那么如何基于一个成熟的Hybris平台进行前后端分离？接下来，我们将会逐一剖析这个演变过程。

Hybris平台Web层现状

众所周知，Hybris平台是一套成熟的电商解决方案，当然也包括Web层的定制化。由于Hybris平台项目至今已经经历过许多版本，对电商的核心流程进行了不同程度上的重组与优化。对于Web层，相对于核心流程来说，升级的速度和频率则显得稍微缓慢。慢慢的我们会发现，在当前前端技术突飞猛进的发展趋势下，Hybris平台Web层的技术体系会变的相对陈旧，比如：缺少了动静分离。因此，在这个技术体系下进行Web层的二次研发，往往还面临着前后端耦合依赖的局面，导致项目进度缓慢。

Hybris平台Web层架构的不足

Hybris平台Web层基于传统的服务端MVC（Model-View-Controller）设计模式，传统的服务端MVC架构在为我们提供优势的同时也会带来以下不足：

1. 对于简单的页面，严格遵循MVC，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率
2. 视图与控制器之间过于紧密的连接。视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
3. View的渲染通过服务端完成，最终呈现给浏览器的是带有Model的视图页面，性能无法得到很好的优化
4. 控制器会变得复杂，很多人会在Controller（Spring），Action（Struts）中写业务代码已经变得很常见，所有的操作都在控制器中，导致业务与控制器相耦合
5. 对象间接地通过控制器耦合在一起，一个对象在控制器中查询获得，然后复制给另外一个对象，这两个对象就耦合在一起
6. View通过服务端完成后，视图页面包含CSS, JS等资源，这些资源需要重新请求（虽然可能已经进行了缓存）

Hybris平台前后端协作的痛点

由于Hybris平台基于传统的服务端MVC（Model-View-Controller），在这个模式下，前后端协作模式一般采用以下两种方式：

1. 前端直接在服务端View中编写模版，这样做的问题在于，编写的过程中强依赖服务端环境。在服务端没有完成的情况下，前端无法进行完整测试
2. 前端先编写静态原型，完成后，后端在View中套用静态原型。这样做的问题在于，服务端需要对前端代码进行浏览，以免出错

这两种协作方式都存在问题。

在模式一下，前端必须掌握一定的服务端JSP技术，并且还需要对Hybris平台内部View的划分机制有一定的了解。因此，学习成本是我们第一要面对的问题。此外，视图的测试依赖服务端环境，导致测试滞后。

在模式二下，首先带来的是时间、成本的消耗，静态原型对于用户来说不是最终的产品，只是开发过程中的一个过渡品。其二，将静态原型转换到服务端View的过程中，后端开发人员需要了解前端的设计，比如：如何找到正确的切分点将一个完整的静态页面切分成若干小的片断，并应用于服务端。在比如：如何正确地使用前端的第三方库？这些问题，不同的前端技术有着不同的做法，因此当后端开发人员在套用静态原型的过程中，无形当中增加了了解，学习前端技术的成本。其三，在静态原型没有完成情况下，如果服务端开发工作已经完毕，那么前后端集成工作则处于等待状态