为什么要前后端分离

如果前端实现与后端技术无关，那页面呈现的部分就可以共用，不同的后端技术只需要实现后端业务逻辑即可。

其根本要解决的问题就是把数据和页面剥离开来。应对方法的技术是现成的，前端用静态网页相关技术，html+css+javascript，通过ajax技术调用后端提供的业务接口。前后端协商好接口方式，通过http提供，统一使用post维持。接口数据结构使用xml实现，前端jquery解析xml很方便，后端对xml的处理工具就更多了。。。

这种构架从本质来讲是soa（面向服务构架）。当后端不提供页面的时候，就变成了只是纯粹的通过 web api 来提供数据和业务之间的交互，web前端就变成了纯粹的客户端角色，与WinForm、移动端应用属于同样的角色。------统称为前端

前后端分离之后，两端的开发人员都轻松不少，由于技术和业务都更专注，开发效率也提高了。分离带来的好处渐渐体现出来：

1. 前后职责分离

前端倾向于呈现，着重处理用户体验相关的问题；后端则倾处于业务逻辑、数据处理和持久化等。在设计清晰的情况下，后端只需要以数据为中心对业务处理算法负责，并按约定为前端提供 API 接口；而前端使用这些接口对用户体验负责。

2. 前后技术分离

前端可以不用了解后端技术，也不关心后端具体用什么技术来实现，只需要会 HTML/CSS/JavaScript 就能入手；而后端只需要关心后端开发技术，除了省去学习前端技术的麻烦，连 Web 框架的学习研究都只需要关注 Web API 就好，而不用去关注基于页面视图的 MVC 技术（并不是说不需要 MVC，Web API 的接口部分的数据结构呈现也是 View），不用考虑特别复杂的数据组织和呈现。

3. 前后分离带来了用户用户体验和业务处理解耦

前端可以根据用户不同时期的体验需求迅速改版，后端对此毫无压力。同理，后端进行的业务逻辑升级，数据持久方案变更，只要不影响到接口，前端可以毫不知情。当然如果需求变更引起接口变化的时候，前后端又需要坐在一起同步信息了。

4. 前后分离，可以分别归约两端的设计

后端只提供 API 服务，不考虑页面呈现的问题。实现 SOA 架构的 API 可以服务于各种前端，而不仅仅是 Web 前端，可以做到一套服务，各端使用；同时对于前端来说，不依赖后端技术的前端部分可以独立部署，也可以应于 Hybrid 架构，嵌入各种“壳”（比如 Electron、Codorva 等），迅速实现多终端。

前后分离架构
任何技术方案都不是银弹，前后分离不仅带来好处，也带来矛盾。我们在实践初期，由于前端团队力量相对薄弱，同时按照惯例，所有业务处理几乎都是由后端（原来的技术骨干）来设计和定义的，前端处理过程中常常发现接口定义不符合用户操作流程，AJAX 异步请求过多等问题。毕竟后端思维和前端思维还是有所不同——前端思维倾向于用户体验，而后端思维则更倾向于业务的技术实现。

除此之外，前后分离在安全性上的要求也略有不同。由于前后分离本质上是一种 SOA 架构，所以在授权上也需要按 SOA 架构的方式来思考。Cookie/Session 的方式虽然可用，但并不是特别合适，相对来说，基于 Token 的认证则更适合一些。采用基于 Token 的认证就意味着后端的认证部分需要重写……后端当然不想重写，于是会将皮球踢给前端来让前端想办法实现基于 Cookie/Session 的认证……于是前端开始报怨（悲剧）……

谁来主导

这些矛盾的出现，归根结底在于设计不够清晰明确。毫无疑问，在开发过程中，主导者应该是架构师或者设计师。然而实际场景中，架构师或者设计师往往也是开发人员，所以他们的主要技术栈会极大的影响前后端在整个项目中的主次作用。这位骨干处于哪端，开发的便捷性就会向哪端倾斜。这是一个不好的现象，但是我们不得不面对这样的现状，我相信很多不太大的团队也面临着类似的问题。

如果没有良好的流程规范，通常前端接触的到角色会比后端更多（多数应用型项目/产品，并非所有情况）。

前端开发人员会受到项目/产品经理或客户的直接影响：这个地方应该放个按钮，那个操作应该这么进行……；
前端还要与美工对接——这样的设计不好实现，是否可以改成那样？客户要求必须这么操作，但是这个设计做不到；
前端还要跟后端对接，对于某些应用，甚至是多个后端

个人认为啊：前端可以成为项目沟通的中心，所以比后端更合适承担主导的角色。

前后分离的测试

前后分离之后，前端的测试将以用户体验测试和集成测试为主，而后端则主要是进行单元测试和 Web API 接口测试。与一体化的 Web 应用相比，多了一层接口测试，这一层测试可以完全自动化，一旦完成测试开发，就能在很大程度上控制住业务处理和数据错误。这样一来，集成测试的工作量会相对单一也容易得多。

前端测试的工作相对来说减轻不了多少，前后分离之后的前端部分承担了原来的集成测试工作。但是在假设 Web API 正确的情况下进行集成测试，工作量是可以减轻不少的，用例可以只关注前端体验性的问题，比如呈现是否正确，跳转是否正确，用户的操作步骤是否符合要求以及提示信息是否准确等等。

对于用户输入有效性验证这部分工作在项目时间紧迫的情况下甚至都可以完全抛给 Web API 去处理。不管是否前后端分离，Web 开发中都有一个共识：永远不要相信前端！既然后端必须保证数据的安全性和有效性，那么前端省略这一步骤并不会对后端造成什么实质性的威胁，最多只是用户体验差一点。但是，如果前后端都要做数据有效性验证，那一定要严格按照文档来进行，不然很容易出现前后端数据验证不一致的情况（这不是前后分离的问题，一体化架构同样存在这个问题）。

小结
总的来说，前后分离所带来的好处还是很明显的。

• 但是具体实施的时候需要一个全新的思考方式，而不是基于原有一体化 Web 开发方式来进行思考。
• 前后分离的开放方式将开发人员从复杂的技术组合中解放出来，大家都可以更专注于自己擅长的领域来进行开发，但同时也对前后端团队的沟通交流提出了更高的要求，前后端团队必须要一同设计出相对稳定的 Web API 接口（这部分工作其实不管是否前后端分离都是少不了的，只是前后分离的架构对此要求更高，更明确地要求接口不只存在于人的记忆中，更要文档化、持久化）。