Design patterns 是否有用于处理未知对象存储的设计模式？

我正在编写一个REST框架，我想实现OAuth2.0。问题是，我不希望对运行此操作的数据库有任何限制

所以我考虑实现它的方式是让开发人员实现他们自己的数据存储类，它实现了我可以与之交互的方法。我在Python中工作，所以没有办法像java中那样定义接口，但我正在创建一个基类，它只为任何方法调用引发NotImplemented，开发人员应该将其子类化

对于我的情况，数据存储对象将具有如下方法：

class DataStore(object):
    def store_client(client_id, client_secret, client_urls):
        ...

    def get_client(client_id, client_secret)
        ...

    def store_token(client_id, token):
        ...

....

开发人员将使用他们选择的数据存储方法实现这些方法，尽管我将提供一些通用数据库的实现

---

有更好的方法吗？

我将说明这是一种替代方法，可能更好，也可能不更好，或者更适合您的需要。您在示例中展示的是传统的DAO或数据存储类型模式。其中，对象模型公开执行所有CRUD操作的方法：读取、更新、创建和删除。这样做的缺点是，当查询或查询数据本身需要更多的逻辑时，一个简单的3-4个公开方法类可以发展成20多个方法

这就是你开始思考每个单独的行为是一个不同的、独立的身份。因此，您可能有一个具有简单接口的“访问器”对象，如：

 class GetClient(object):
   def get(self, client_id):
     pass

但在主题上有几种不同的变体，如：

 class AuthenticatedGetClient(GetClient):
   def __init__(self, authorization_service, current_user):
     #stuff
   def get(self, client_id):
     if self.auth_svc.permit(self.current_user, client_id):
       #actual client get, perhaps you need to screen out additional details, etc.

这更多地遵循了一种方法，即您向视图表示的模型实际上可能是不同的，或者是几个DB模型的合并。示例：用户模型可能存储用户名，而地址存储地址，并且数据库中实际上不存在“配置文件”模型

---

这里的好处是，您可以混合使用更复杂的访问模式，同时抽象出数据存储并减少向任何其他开发人员提供的不同API调用的数量。缺点是，您需要为每个CRUD操作创建不同的对象表示。

没有“更好”的方法，有其他方法，但仅此而已。每个人都有自己的权衡。我有兴趣在答案中了解更多关于这些备选方案的信息。