1

我发现 Pony 是用于小型项目的好工具。但是，当您的项目增长到某个点时，将 @db_session 放置在您的函数中对于编写的每个函数几乎都是强制性的。

遵循 SOLID 原则，我正在尝试连接 PonyORM。然而，事实证明并不像我想象的那么容易。

class CustomQuery(object):
    def __init__(self, query):
        self.obj = query

    def __getattr__(self, attr):
        return getattr(self.obj, attr)

    @db_session
    def count(self):
        return self.obj.count()

    @db_session
    def first(self):
        return self.obj.first()

    @db_session
    def without_distinct(self):
        return self.obj.without_distinct()

    def __iter__(self):
        return self.obj.__iter__()


class DatabaseService:

    @staticmethod
    @db_session
    def select(*args):
       # This will be select() interface
        return CustomQuery(select(*args))

这是我试图做的一个例子。但是，当我执行以下操作时遇到了问题：

# User has many PhoneNumbers

user = User.select().first() 

assert isInstance(user, CustomQuery)

user.phone_numbers.count()

如果我理解正确的话，在做user.phone_numbers.count()一个新pony.orm.core.Query对象的时候会创建一个。

我想改为返回一个CustomQuery允许 db_session 持续存在的对象。

关于如何做到这一点的任何想法？或者其他人处理一堆@db_session装饰器的其他方式？

4

1 回答 1

1

首先，在我看来，您正在尝试与 Pony 的设计理念作斗争：@db_session 装饰器的整个想法是让您不必处理数据库管理（样板代码、打开/关闭数据库、SQL、回滚等）。 ) 而且我知道您想自己做，因此使@db_session 的想法没有实际意义

其次，本质上，除非装饰器在调用时有副作用，否则它只是一个以调用开始和结束的包装器。因此，让它持续存在的想法也与其预期目的相反。

总而言之，如果你想做 pony 提供给你的设施的工作，你最好干脆放弃使用 pony。

也许，你应该问问自己为什么要小马以及为什么要摆脱装饰器。下定决心将帮助您为自己做出正确的决定。

高温高压

于 2020-11-19T10:03:53.873 回答