Python微服务工程,有必要增加DAO层么?

292 views
Skip to first unread message

GeekGao

unread,
Jul 13, 2021, 7:52:44 AM7/13/21
to python-cn(华蟒用户组,CPyUG 邮件列表)
我想是受到了Java 的“熏陶”,发现加了DAO层后代码太冗长了。对了这里我使用的是PonyORM。越写越别扭了,各位大佬们对此有什么建议?

fei

unread,
Jul 13, 2021, 9:23:00 AM7/13/21
to pyth...@googlegroups.com
其实如果把 DAO 理解成 service 里的关于 data 操作的 util ,从这个层上考虑,其实还是蛮好加的。
但即便这样,我也还是更喜欢放到 service 里去。

On Tue, Jul 13, 2021 at 7:52 PM GeekGao <xing...@126.com> wrote:
我想是受到了Java 的“熏陶”,发现加了DAO层后代码太冗长了。对了这里我使用的是PonyORM。越写越别扭了,各位大佬们对此有什么建议?

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到python-cn+...@googlegroups.com
要在网络上查看此讨论,请访问https://groups.google.com/d/msgid/python-cn/a84c934c-d832-4b88-80c0-fea3b082d096n%40googlegroups.com

Shawn Tian

unread,
Jul 13, 2021, 9:25:56 AM7/13/21
to pyth...@googlegroups.com
大项目尝试过加各种 DAO,但是确实写起来太繁琐了,「繁琐」主要 Python IDE 一般很难智能地识别各种 class,导致写起来比较头疼,包括 vscode/pycharm 等。

而且 Go/Java 这种 IDE 可以帮忙做很多辅助工作,虽然代码量大,但架不住不用脑子啊。

On Tue, Jul 13, 2021 at 7:52 PM GeekGao <xing...@126.com> wrote:
我想是受到了Java 的“熏陶”,发现加了DAO层后代码太冗长了。对了这里我使用的是PonyORM。越写越别扭了,各位大佬们对此有什么建议?

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到python-cn+...@googlegroups.com
要在网络上查看此讨论,请访问https://groups.google.com/d/msgid/python-cn/a84c934c-d832-4b88-80c0-fea3b082d096n%40googlegroups.com


--
Best regards
Shawn Tian

vicalloy

unread,
Jul 13, 2021, 8:40:21 PM7/13/21
to pyth...@googlegroups.com
去掉dao,python orm的表现能力已经够强了,别给自己找麻烦。

On Tue, Jul 13, 2021 at 19:52 GeekGao <xing...@126.com> wrote:
我想是受到了Java 的“熏陶”,发现加了DAO层后代码太冗长了。对了这里我使用的是PonyORM。越写越别扭了,各位大佬们对此有什么建议?

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到python-cn+...@googlegroups.com
要在网络上查看此讨论,请访问https://groups.google.com/d/msgid/python-cn/a84c934c-d832-4b88-80c0-fea3b082d096n%40googlegroups.com
--

rong zhao

unread,
Jul 13, 2021, 8:45:19 PM7/13/21
to pyth...@googlegroups.com
这个还是取决于你项目的复杂度,DAO本质上并不是说你非要它不可,也不是说只能用它去操作数据库。

本质上它是为了屏蔽服务层到数据持久化层的依赖,服务层级的代码不需要去考虑下一层数据是怎么持久化的,低下可能是个关系型数据库,也可能是个NoSql。

说到底是个Design Pattern的问题,当你觉得有它麻烦时,就不要用了,当你觉得需要它时,不要害怕重构,并且积极重构。
> 要在网络上查看此讨论,请访问https://groups.google.com/d/msgid/python-cn/CAATL4ywLM7j47V9CDQvfEoRGKAnTO8c%2BdvWvECd2MCBkNOXe_g%40mail.gmail.com

Frost Ming

unread,
Jul 13, 2021, 8:45:34 PM7/13/21
to pyth...@googlegroups.com
引用我在helloflask上的一个简短回答


GeekGao <xing...@126.com> 于2021年7月13日周二 下午7:52写道:
我想是受到了Java 的“熏陶”,发现加了DAO层后代码太冗长了。对了这里我使用的是PonyORM。越写越别扭了,各位大佬们对此有什么建议?

--

Zagfai

unread,
Jul 14, 2021, 12:18:46 AM7/14/21
to python-cn(华蟒用户组,CPyUG 邮件列表)
存储还是在高速发展的过程中,低层仓库的api和使用模式不断变化,会导致数据接入层也不断变化,现在所有的抽象方式都没办法囊括变化,最近也看了下pony,但本质上还是一样,没有看到更高层次包容性的抽象。
所以。。还是坚持做一个面向业务,作为存储的数据接入层就可以了,层内变化随着存储变化而变化,能设计到暴露的业务性接口尽量少变化就好。

GeekGao

unread,
Jul 14, 2021, 2:17:37 AM7/14/21
to python-cn(华蟒用户组,CPyUG 邮件列表)
 假如nodesql 一样可以抽象出实体对象呢例如MongoEngine ?我觉得在这里是表现力的问题了,数据抽象已经靠ORM来做映射过了

GeekGao

unread,
Jul 14, 2021, 2:19:00 AM7/14/21
to python-cn(华蟒用户组,CPyUG 邮件列表)
“会导致数据接入层也不断变化”? 假如,我们就是个管理系统呢,不是什么超大型的互联网项目,预期也就是MySQL、ES和Redis  似乎没什么存储技术性的变化。

GeekGao

unread,
Jul 14, 2021, 2:19:55 AM7/14/21
to python-cn(华蟒用户组,CPyUG 邮件列表)
我看Rediit的代码,都是放到了models里写的,可能未必是最佳实践吧。Ref:https://github.com/reddit-archive/reddit/tree/master/r2/r2/models

GeekGao

unread,
Jul 14, 2021, 2:20:37 AM7/14/21
to python-cn(华蟒用户组,CPyUG 邮件列表)
是这样,比较烦,要文件跳转来跳转去的看属性和方法
Reply all
Reply to author
Forward
0 new messages