We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
介绍python的web项目怎么写,比如要不要MVC啊,怎么MVC啊,要不要Restful啊,怎么Restful啊
The text was updated successfully, but these errors were encountered:
之前工作时整理过一份 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修复也比以前困难。
Sorry, something went wrong.
Thanks a lot.
No branches or pull requests
介绍python的web项目怎么写,比如要不要MVC啊,怎么MVC啊,要不要Restful啊,怎么Restful啊
The text was updated successfully, but these errors were encountered: