jhao104 / django-blog

django搭建博客

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

如果可以写一篇博客就好了,嘿嘿

pplmx opened this issue · comments

介绍python的web项目怎么写,比如要不要MVC啊,怎么MVC啊,要不要Restful啊,怎么Restful啊

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

image

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

image

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

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

Thanks a lot.