Python中使用Django搭建APP服务端遇到的一系列问题

Django 刚入门,打算使用 Django 搭建 APP 的服务端。APP 类型类似于团购外卖这种。有几个问题,困惑了好久。希望这方面有经验的,能给一些指导。谢谢了。
1.是否需要使用 django rest framework 这种框架?我也花时间看了 django-rest-framework,不过根据我的理解,这种框架直接增删改查数据还是挺方便的,但是一旦涉及到一些逻辑处理,是不是不大适合?例如一个订单,可能涉及多张表查询汇总,修改字段状态什么的。我自己感觉还是使用原先 Django 的 View 层中 get、post 方法处理比较方便。
2.假如不使用 rest framework,我自己在 view 的 get,post 方法中形成 json 数据返回给客户端。那么 django 中 form 提交所涉及的 csrf 的机制是不是就要废弃掉了?自己和客户端商量安全的机制?
3.这方面有没有什么开源的项目或者代码能参考的,假如有,麻烦告知下。谢谢各位。
Python中使用Django搭建APP服务端遇到的一系列问题


15 回复

一听就是坏习惯,View 就是表现层,我觉得他们做数据校验都算多了。你还要将业务逻辑写在里面。你应该封装一个 Service 类,这样你不管换什么 View 都能很好地复用。
项目的话应该参考 sentry 就差不多了吧


我无法理解你的问题

数据校验在 serializer,如果都封装一个 service 类,传参数都够烦人了。

> 这方面有没有什么开源的项目或者代码能参考的
https://github.com/taigaio/taiga-back

有啊 openstack




drf 默认不是校验了数据吗? 你们还校验什么场景下的数据?

django 不算是一个标准的 MVC 构架,它的 views 文件相当于其他框架的 controller,并不是表现层

1 是的 2 不是

明天电脑具体说

我来一一回答
先看楼主的说法,他可不仅要将数据校验放 view,他是想要将一部分业务逻辑也放这里,这个才是我要否定的。所有东西都放第一个地方,重构火葬场

drf 默认校验了一部分数据,不过只是我觉得它实现的跟我想要的不一样,我更倾向于在类似中间件之类的部件做完这些。将所谓的校验逻辑从 view 里面脱离出来,可能更倾向于 view->validation->model/bussiness

嗯 Django 不是一个 MVC 框架,我认同,但是哪怕 MVC 也好,MVT 也好,Controller 对应的部分也不应该写业务逻辑,这个没毛病吧,Controller 应该是传递对应的参数给 Model 层,让 Model 层对应的模块去处理业务逻辑。此处我会将数据校验也当作一部分业务逻辑,这才是我认为 drf 的数据校验放在 view 不符合我个人的地方

感谢您的回答,不过我问题其实是关于 django-rest-framework 是否是用便捷程度的问题,我目前对 restful 风格还是有些陌生,不知道逻辑处理怎么在 rest 框架中体现,想直接用 django 返回 json 数据,但是看到大家都在推荐 rest 写 api 接口,所以比较困惑。

烦请详述

平心而论,drf 还是蛮便捷的。一般接口直接 Model, ModelSerializer, ModelViewSet 三连就好了,当然你有特殊校验就得你自己写 Serializer 来校验了,跟数据库相关的需要在业务层进行校验。

我看的材料,都是 ModelSerializer 对 Model 进行序列化,然后 ModelViewSet 中,通过 queryset 和 serializer 来返回数据。例如:
queryset = Article.objects.all()
serializer_class = ArticleSerializer

给我的感觉是一个 ModelViewSet 只对应一个 Model,把干这个 Model 序列化后返回给客户端就完事了。
但是一般的 APP 接口逻辑不可能只是获得这样的模型对象的,例如登录,我要从客户端传入 username 和 pwd,进行验证,可能还要查询、设置其他表一些标志位,形成 user 的数据,返回给客户端。这样的逻辑处理,和涉及好几个表之间的操作,在 django rest framework 中,怎么操作呢?

他们提供 perform_create 这样的钩子,你重写这个钩子就好了,update, delete 的都有,具体请看文档

DRF 库提供了很多我并不会用到的功能,比如登录验证,权限管理,API 版本号管理,限流、自动翻页等等,这些我更侧重独立和手动的处理。

Generic Views 一直是一个让我感到疑惑的东西,看似写起来简单,代码量很少,像是填充一些预定义的变量和方法,简单的增删查改会方便一点,但是在实际复杂的业务场景下,可能导致问题复杂化,并没有显式的写出操作过程更清晰。
所以我仿照 DRF 的 APIView,继承 Django 的 View,自己写了一个新的 APIView,包含了核心功能,解析 JSON,同时增加了部分常用方法,比如 validate_serializer、self.success、self.error 和 self.paginate 等等。

大致的代码就是

class UserProfileAPI(APIView):
(ChangeUserProfileSeralizer)
def put(self):

if err:
return self.error(“保存失败”)
return self.success(UserProfileSerailzier(user_profile).data)

class ProblemAPI(APIView):
def get(self):
return self.success(self.paginate(request, Problem.objects.all(), ProblemSerializer)))

CSRF 和 DRF 没关系,是 Django 的验证,token 也可以在 HTTP 头中传递

回到顶部