是否需要前后端分离的框架

前后端分离意味着讨论是否需要前后端分离的框架，先要了解什么是前后端分离的框架。再说说它的趋势。

什么是前后端分离？

前后端分离要解决的问题是解耦——可以解耦复杂的业务逻辑，解耦架构。前端使用各种单页面程序的框架。后端采用webapi提供数据服务。

前后端分离意味着，前后端之间使用 JSON 来交流，两个开发团队之间使用 API 作为契约进行交互。从此，后台选用的技术栈不影响前台。当后台开发人员选择 Java 的时候，我可以不用 JSP 来编写前端页面，继续使用我的 React 又或者 Vue。而我使用 Vue时，也不影响后台使用某一个框架。

前后端分离在过去的这几年里，确实特别的热闹。但是我们怎么才能知道，是不是需要这样的架构呢？

• 页面交互是否复杂 ？ 是简单的提供页面给用户浏览？或者想要支持复杂的用户操作？
• 是否需要搜索引擎优化？如果需要的话，那么从一开始我们就需要考虑后端渲染。
• 能提升开发效率吗？ 是否能有效的提升开发效率，根据自己的技术团队做判断。
• 是否会提供 API 给 APP？如果我们已经有一个 API 提供给 APP，那么要做这件事就很容易了。如果未来会有的话，那么我们更应该尝试去分离。
• 前端的修改是不是非常频繁？如果不需要经常修改的话，那么这种优化便没有优势。

最后，如果领导说，我们要做成前后端分离，那就做呗！很多时候，一些技术决策都会由于战略原因，而发生一些有意思的变化。

前后端分离将遇到哪些挑战

当我们决定需要前后端分离时，我们仍然还需要面对一系列的问题：

• 是否足够的安全？如果我们设计出来的架构不够安全，那么这一系列的操作都是白搭。
• 是否有足够的技术来支撑前后端分离？有没有能力创建出符合 RESTful 风格的 API？
• WebApi接口的制定难度大不大？是让前端还是后台主导？
• 前后端协作的成本高不高？前端和后台两个团队是不是很容易合作？是不是可以轻松地进行联调？
• 前后端职责是否能明确？即：后台提供数据，前端负责显示。
• 是否建立了错误追踪机制？能否帮助我们快速地定位出问题。

当我们在不同的项目组上尝试时，就会发现主要的挑战是沟通上的挑战，而非技术上的局限。

前后端分离的核心：后台提供数据，前端负责数据呈现和交互

传统的 MVC 架构里，因为某些原因有相当多的业务逻辑，会被放置到 View 层，也就是模板层里。换句话来说，就是这些逻辑都会被放到前端。我们看到的可能就不是各种if、else还有简单的equal判断，还会包含一些复杂的业务逻辑，比如说对某些产品进行特殊的处理。

如果这个时候，我们还需要做各种页面交互，如填写表单、Popup、动态数据等等，就不再是简单的和模板引擎打交道了。我们需要编写大量的 JavaScript 代码，因为业务的不断增加，仅使用 jQuery 无法管理如此复杂的代码。

输出逻辑：数据显示

而仅仅只是因为逻辑复杂的前端代码，无法影响大部分团队进行前后端分离——因为它没有业务价值。实际上是先有了单页面应用，才会出现前后端分离。单页面应用可以让用户不需要下载 APP，就可以拥有相似的体现。并且与早期的移动网页相比，拥有更好的体验。

为了达到这样的目的，后台似乎返回对应的 Model 即可，稍微修改一下 Controller 的逻辑，然后返回这些数据。

{
    "Status": 2000,
    "Message": null,
    "NewID": null,
    "Entity": {
        "Street2": "23323232",
        "Country": "China",
        "Type": 0,
        "ID": "97e282f1b87445a7a80bd2bda84e8a25",
        "CompanyName": "TempSen co.,32ii",
        "Street": "shenzhuan road877",
        "City": "shanghai",
        "States": "Shanghai",
        "Zip": "200102",    
        "IfReceiveNotification": 0,
        "CompanyID": "f6e463da76844ec99fc5c3201ef86653",
        "AddTime": "2017-12-05T06:21:27",
        "Creator": "6ae262c8c6c74688ae0d1c9695556d83"
    },
    "TotalPages": 0,
    "TotalRowsCount": 1
}

前端在一个 API 请求之后，可以直接渲染这些数据成 HTML。与此同时，后台应该按用户的偏好，来显示时间格式，根据特定的要求进行排序。前端只需要遍历这个数组，随后取出相应的值显示即可，不需要做任何的逻辑处理。

但是，很多时候还是会对数据存在本地，之后做些处理，比如对其进行排序，筛选等等的操作。除此，还有诸如表格、图表等等的高级样式，也需要处理这些数据。

而当用户需要提交数据的时候，这些逻辑就会落到前端上。

不可避免的前端逻辑：提交的数据验证

如果一个前端应用只显示数据的话，那么这个应用就没有充足的理由，做成一个单页面应用——单页面应用是为了更好的交互而存在的。当我们注册、登录、购买东西时，就需要开始与数据进行处理。

合理的表单验证模式应该是：双边验证。

前端在用户输入的过程中就需要实时地检查，是否带有特殊符号、值是否是在允许的范围内、是不是符合相应的规范等等。而不是等用户填写完内容并提交后，再由服务端来告诉用户说，“你的用户名不符合规范”。

服务在收到前端收到的数据后，不管前端有没有进行验证，都应该按后台的逻辑进行验证。

于是乎在这个时候，这些逻辑就被无可避免地放到前台里了。

前后端分离的框架，总的来说比较先进的，会是一种潮流，一种趋势。但是需要根据自身的特点，慎重选择。其实怎么分离，工作两不会因为分离而减少，相反会因为享受解耦的便利，带来更多的工作量，比如沟通，然后是技术的多样性也的增加企业的成本。