如果可以写一篇博客就好了,嘿嘿 about django-blog HOT 2 OPEN

之前工作时整理过一份
1、原开发模式：
采集平台原开发模式是通过Template渲染的方式(MVC模式)。浏览器把请求交给Django处理，Django根据视图函数，读写数据或做些处理操作，最后通过Template渲染成html页面返回给浏览器。处理流程图：

2、前后端分离开发：
后端只需要提供api接口，前端通过异步方式调用api获取数据。这样后端负责数据处理，前后只负责展现。大致流程类似这样:

3、为何选择前后端分离：
台采用未分离的开发模式，前后端代码混杂在一起，这种MVC架构就决定了前端需要高度依赖后端。
当时为了协作开发，当时提出了两种方案:
（1）依然使用不分离的模式：前端写好静态demo，后端翻译成Template模板。这样后端人员会重复工作；
（2）采用分离的方式: 后端重构原有代码只提供RESTful接口，由前端负责展现。
后来商量确定了采用第二种方案。

4、分离后的优缺点:
分离前：
前后端混杂：前后端职责不清楚，前端代码以Template形式由后端维护，代码混杂在一起。这样代码修改更新都非常麻烦。再加上采集平台业务逻辑比较复杂，久而久之，代码的维护性就极差；
开发效率：如果前端不熟悉模板语言，还需要将前端代码翻译成Template。
多人协作: Django的Template高度依赖Views，不适合多人协作开发模式。
分离后：
服务器压力：后端只需要返回json数据，页面渲染、数据验证、处理等均可以在前端完成。这样可以将服务端的压力减少到最小，给用户更流畅的体验；
开发效率: 分离后，后端只需要专心于业务逻辑层的开发；而前端只需要关注数据展现；
多人协作: 前后端分离开发后，只要前后端人员约定好所有api数据传输格式后，便可以各自自行开发，互不影响；
前端发挥局限性： 前端脱离后端约束，可以更加专注页面美化，增加用户体验。
工作量: 分离后后端只需提供数据api不用关心模板渲染，工作量有所减少；但是相反这样前端的工作量会有增加。而且这种开发模式需要花大量的时间在联调和沟通环节，bug修复也比以前困难。

from django-blog.

Thanks a lot.

from django-blog.