多种DAL设计模式

010

我对python比较陌生。我正在构建一个系统,该系统最初将从数据库中获取数据,但是在将来的某个时候,我们将从服务中获取数据。为了解决这个问题,我创建了一个称为BaseDAL的抽象基类,该基类定义了我的数据获取器:

class BaseDAL(object):
    __metaclass__ = ABCMeta

    @abstractmethod
    def get_securities(self):
        pass

    @abstractmethod
    def get_security_data(self, ticker):
        pass

这里的想法是最初的具体实现将从数据库中获取,但是当服务准备就绪时,我将简单地创建另一个从该服务获取的具体实现。

这是针对此类问题的正确设计/解决方案吗?

其次,基于从配置文件读取的类名,有条件地实例化具体提供程序的好方法是什么。我想像这样..但在如何从字符串名称实例化实例方面需要帮助:

class DALFactory(object):
    """reads a config file, creates a concrete provider, and always return that instance"""

    __provider = None
    def __init__(self):
        pass

    @classmethod
    def get_provider(cls):
        if cls.__provider is None:
            cls.__provider = get_provide_type_from_config()

        return cls.__provider
帕特里克·柯林斯

看来您是Java程序员。设计模式,抽象方法和复杂的继承层次结构在Python中实际上是未知的:由于使用鸭子类型,没有令人信服的理由让您的其他DAL*类继承BaseDAL—具有适当命名方法的同级类也能很好地完成工作,冗长程度较低。

Getter和Setter基本上也没有使用:只需访问所需的实际属性即可。如果以后需要将其重构为方法,则可以@property在该方法上使用,而无需进行任何更改。

简单胜于复杂。

编辑:如果DBDalWSDal是您的两个班级,您可以像这样(利用一流的功能)创建一个简单的“工厂”:

def make_dal(name):
    return {
        'DBDal identifier string': DBDal,
        'WSDal identifier string': WSDal
    }[name]()

本文收集自互联网,转载请注明来源。

如有侵权,请联系[email protected] 删除。

编辑于
0

我来说两句

0条评论
登录后参与评论

相关文章