Python中如何优化一个使用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.
目前找到的开源的东西就这么多…
请大神赐教.多谢多谢…
Python中如何优化一个使用Django+SQLAlchemy的项目？
恕哥直言，这也太变态和扭曲了吧？我不是说绝对不可以，而是感觉要自虐的节奏。
你用酱狗就是为了那个内置 ORM 方便好用啊，而且所有的方便省事都是基于这种整合，你非要把一个人的腰部以下截移植到马脖子上，难道就能成为强大的人头马啦？
如果非要 SA 那么上 flask 啊。
你这个用法太奇怪了, 不能继续错下去…
用 DRF, 其实主要用 Serializer + APIView 是最方便, 最灵活的.
不用 DRF viewset 是可以的, 甚至 DRF ModelSerializer, GenericView 之类的都可以少用 (只在开发调试时用).
层主请教一下.
openstack 中很多组件 对数据库的处理都是通过 dbapi 中的函数去操作数据库的 在别的地方从来没见过呢.
想请教一下,这样做的目的是什么?
neutron 这个组件中封装了一层 object. 但是文档上说是为了版本兼容做了一层隔离.我觉得这样写挺好的.
你觉得呢?
我说的不一定对 但是说一下
首先你要知道 openstack 迭代了好多版本,很多代码是为了兼容老版本,方便升级写的,自己设计可以跳过这些不必要的设计
dbapi 这个层, 我猜是因为 openstack 对数据库的操作没做什么优化,性能其实挺差的,很多问题都没处理.比如说什么锁的问题,高并发问题都没考虑过
加了一层 dbapi(一方面可以兼容原有的本地写方式,一方面应该是处于数据库性能上的考虑),这样就相当于数据库中间件客户端了, 有 dbapi 在扩展性、向上版本兼容性上就好很多
nova/neutron 的数据库配置不走本地的话, 是通过 rpc 发到专门写数据库的程序的
由于 openstack 的 rpc 统一用 mq 做的, 自己做的话,这部分不应该走 mq,应该自己实现专门的中间件
如果你的数据库操作不需要转发出去,直接当前进程和数据库通信的话,这层就没必要了
封装 object 也是为了版本迭代和扩展性考虑的,好像思路比较类似 java 的 dao 层？
因为 openstack 的 rpc 可以设置专门的序列化方式, 所以可以轻松的把 json 转化为对应的 python object （对应上封装的那层 object ）对象,然后这些 object 就可以直接转为对应数据库操作了.这玩意是一整套的实现来的
如果自己的程序不需要迭代更新兼容,这一层其实也没有必要,直接拿 json 发过来数据进行数据库操作就行了
