抽象数据访问的python设计模式:优缺点？

Question

我想知道几种方法来完成从主应用程序中抽象出数据存储访问，还有一个小示例，IoC框架看起来有点夸张，可能是通过构造函数参数(外观)传递对象。

下面的伪代码是做事情的好方法吗?我如何用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)

Answer 1

我要说的是，以上不是一个很好的方法。使用者(在本例中为main.py)不应该知道任何关于模型实现细节的信息。我可以做的是将键/值对存储在外部配置文件中，供模型用来确定要使用的引擎。

Answer 2

您即将创建另一个ORM层。

与其浪费大量时间重新发明轮子，不如学习一下现有的对象关系模型，并使之适应您选择的noSQL数据库引擎。

例如，首先使用SQLAlchemy作为一种对象关系映射，它可以为SQL做您想做的所有事情(甚至更多)。

由于Python的鸭子类型，您可以发明一个兼容的Python或Repository ORM，或者您认为重要的任何其他东西。

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

Answer 3

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

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