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

2019-02-13 14:53:32 +08:00
 chaleaochexist
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.


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

请大神赐教.多谢多谢...
2403 次点击
所在节点    Python
10 条回复
xpresslink
2019-02-13 15:14:48 +08:00
恕哥直言,这也太变态和扭曲了吧?我不是说绝对不可以,而是感觉要自虐的节奏。
你用酱狗就是为了那个内置 ORM 方便好用啊,而且所有的方便省事都是基于这种整合,你非要把一个人的腰部以下截移植到马脖子上,难道就能成为强大的人头马啦?
如果非要 SA 那么上 flask 啊。
arrow8899
2019-02-13 15:30:57 +08:00
Django + DRF 就可以了吧,serializer + view + model,自带的 ORM 就挺好用,没必要再用 sqlalchemy 了
dcoder
2019-02-14 05:16:36 +08:00
你这个用法太奇怪了, 不能继续错下去...
用 DRF, 其实主要用 Serializer + APIView 是最方便, 最灵活的.
不用 DRF viewset 是可以的, 甚至 DRF ModelSerializer, GenericView 之类的都可以少用 (只在开发调试时用).
chaleaochexist
2019-02-14 09:50:52 +08:00
@dcoder 不过 Serializer + APIView 如果只用这个组合那么使用 sqlalchemy 似乎也没什么毛病啊...这俩东西都不依赖 django orm
lolizeppelin
2019-02-14 17:47:22 +08:00
为啥不整个抄 openstack 那套捏

连 http 服务都一起啊....
chaleaochexist
2019-02-14 18:14:50 +08:00
@lolizeppelin 我猜的.不是我写的.
chaleaochexist
2019-02-14 18:15:10 +08:00
@lolizeppelin 不过 openstack 对应 sqlalchemy 部分的处理感觉...理解不能.
lolizeppelin
2019-02-14 18:42:31 +08:00
@chaleaochexist

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

所以风格完全不一样啊
chaleaochexist
2019-02-14 18:47:00 +08:00
@lolizeppelin 层主请教一下.
openstack 中很多组件 对数据库的处理都是通过 dbapi 中的函数去操作数据库的 在别的地方从来没见过呢.

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

neutron 这个组件中封装了一层 object. 但是文档上说是为了版本兼容做了一层隔离.我觉得这样写挺好的.
你觉得呢?
lolizeppelin
2019-02-15 16:36:14 +08:00
@chaleaochexist

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


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

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

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

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

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

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/534556

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX