一个 django+sqlalchemy 的项目,如何优化?

django + django_restframework + sqlalchemy 的奇怪组合.

导致 django_restframework 的很多功能都没有使用.譬如 serialize router viewset 等.
另外,找 django 插件也不好找.
最后,这个项目的写法感觉是参考了 openstack 的写法.没有多少 django 的影子.
后端目前三个人,我不是负责人.

将错就错?继续这么写? 业务层堆了一堆业务逻辑...

另外请教 sqlalchemy orm 的调用一般放在哪里?有没有比较成熟的,比较大的开源项目可以参考参考.

一般 django orm 都是自定义 manager 和 Model 去解决分层的问题.(我之前是这么干的)

openstack 中的部分项目有使用 object(neutron),将 sqlalchemy 和 control 层做了隔离.
有的项目通过 dbapi.也就是将数据库操作封装成一个一个函数去处理.
redash 中是直接在 control 层里面写 SQL.

目前找到的开源的东西就这么多...

请大神赐教.多谢多谢...

django SQLAlchemy OpenStack orm

10 条回复 • 2019-02-15 16:36:14 +08:00

xpresslink

2019 年 2 月 13 日

恕哥直言，这也太变态和扭曲了吧？我不是说绝对不可以，而是感觉要自虐的节奏。
你用酱狗就是为了那个内置 ORM 方便好用啊，而且所有的方便省事都是基于这种整合，你非要把一个人的腰部以下截移植到马脖子上，难道就能成为强大的人头马啦？
如果非要 SA 那么上 flask 啊。

arrow8899

2019 年 2 月 13 日

Django + DRF 就可以了吧，serializer + view + model，自带的 ORM 就挺好用，没必要再用 sqlalchemy 了

dcoder

2019 年 2 月 14 日

你这个用法太奇怪了, 不能继续错下去...
用 DRF, 其实主要用 Serializer + APIView 是最方便, 最灵活的.
不用 DRF viewset 是可以的, 甚至 DRF ModelSerializer, GenericView 之类的都可以少用 (只在开发调试时用).

chaleaochexist

2019 年 2 月 14 日

@dcoder 不过 Serializer + APIView 如果只用这个组合那么使用 sqlalchemy 似乎也没什么毛病啊...这俩东西都不依赖 django orm

lolizeppelin

2019 年 2 月 14 日

为啥不整个抄 openstack 那套捏

连 http 服务都一起啊....

chaleaochexist

2019 年 2 月 14 日

@lolizeppelin 我猜的.不是我写的.

chaleaochexist

2019 年 2 月 14 日

@lolizeppelin 不过 openstack 对应 sqlalchemy 部分的处理感觉...理解不能.

lolizeppelin

2019 年 2 月 14 日

@chaleaochexist

因为是好多人写的每个组件都是不同的一群人写的

所以风格完全不一样啊

chaleaochexist

2019 年 2 月 14 日

@lolizeppelin 层主请教一下.
openstack 中很多组件对数据库的处理都是通过 dbapi 中的函数去操作数据库的在别的地方从来没见过呢.

想请教一下,这样做的目的是什么?

neutron 这个组件中封装了一层 object. 但是文档上说是为了版本兼容做了一层隔离.我觉得这样写挺好的.
你觉得呢?

lolizeppelin

2019 年 2 月 15 日

@chaleaochexist

我说的不一定对但是说一下
首先你要知道 openstack 迭代了好多版本,很多代码是为了兼容老版本,方便升级写的,自己设计可以跳过这些不必要的设计

dbapi 这个层, 我猜是因为 openstack 对数据库的操作没做什么优化,性能其实挺差的,很多问题都没处理.比如说什么锁的问题,高并发问题都没考虑过

加了一层 dbapi(一方面可以兼容原有的本地写方式,一方面应该是处于数据库性能上的考虑),这样就相当于数据库中间件客户端了, 有 dbapi 在扩展性、向上版本兼容性上就好很多

nova/neutron 的数据库配置不走本地的话, 是通过 rpc 发到专门写数据库的程序的
由于 openstack 的 rpc 统一用 mq 做的, 自己做的话,这部分不应该走 mq,应该自己实现专门的中间件
如果你的数据库操作不需要转发出去,直接当前进程和数据库通信的话,这层就没必要了

封装 object 也是为了版本迭代和扩展性考虑的,好像思路比较类似 java 的 dao 层？
因为 openstack 的 rpc 可以设置专门的序列化方式, 所以可以轻松的把 json 转化为对应的 python object （对应上封装的那层 object ）对象,然后这些 object 就可以直接转为对应数据库操作了.这玩意是一整套的实现来的

如果自己的程序不需要迭代更新兼容,这一层其实也没有必要,直接拿 json 发过来数据进行数据库操作就行了

推荐学习书目

› Learn Python the Hard Way

Python Sites

› PyPI - Python Package Index

› http://diveintopython.org/toc/index.html

› Pocoo

值得关注的项目

› PyPy

› Celery

› Jinja2

› Read the Docs

› gevent