用于抽象数据访问的python设计模式:优点,缺点?

时间:2011-09-06 23:35:01

标签: python design-patterns

我想知道几种方法来完成从主应用程序中抽象出数据存储访问的一些方法,一个小例子,IoC框架似乎有点过分,可能通过构造函数参数(facade)传递对象。

下面的伪代码是一个很好的做事方式,我如何用python填充缺失的部分?

main.py
    resp = Repository(engine=NoSql)  # can easily switch to nosql???
    resp.save("hello");
    resp.select("hello");

repository.py
class Repository:
    def __init__(self, engine):
        self.engine = engine

    def save(self, str)
        engine.save(str)

    def select(self, str)
        engine.select(str)

nosql.py
class NoSql:
    def save(self, str)
        nosql.save(str)

    def select(self, str)
        nosql.select(str)

mysql.py
class MySql:
    def save(self, str)
        mysql.save(str)

    def select(self, str)
        mysql.select(str)

3 个答案:

答案 0 :(得分:2)

您即将创建另一个ORM层。

不要浪费大量时间重新发明轮子,了解现有的ORM,并使其适应您选择的noSQL数据库引擎。

例如,使用SQLAlchemy作为ORM开始,它可以为SQL执行所需的所有操作(以及更多)。

由于Python的鸭子类型,您可以发明兼容的noSQL ORM或Repository ORM或您认为重要的任何其他内容。

然而,不要从头开始重新发明这个轮子。阅读其他一些实现。 SQLObject,Django ORM,SQLAlchemy都是很好的起点。

答案 1 :(得分:1)

我会说上面的内容并不是一个好方法。消费者(在这种情况下为main.py)不应该对模型的实现细节有任何了解。我可能会做的是将键/值对存储在外部配置文件中,供模型用来确定要使用的引擎。

答案 2 :(得分:0)

这是一个可行的解决方案,我在其他项目上做过类似的事情。确保将所有数据库实现保留在数据库类中。 main应该能够在两者之间切换而不做任何改动。如果你需要在切换时对main进行更改,那可能是应该在Sql类中的代码。

我会使Repository成为其他人派生而不是包装器的基类。这样,如果两个实现具有相同或非常相似的代码,您可以将部件移动到存储库中,这样您就不必复制它。