Шаблон проектирования Python для абстрагирования доступа к данным: преимущества, недостатки?

1

Мне было интересно несколько способов добиться абстрагирования доступа к хранилищу данных от основного приложения и небольшого примера, структура 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)
  • 0
    вы пропустили аргумент self в каждом методе ...
  • 1
    @JBernardo "ниже псевдокод ..."
Теги:
design-patterns

3 ответа

0
Лучший ответ

Я бы сказал, что это не отличный способ. Потребитель (в данном случае main.py) не должен знать ничего о деталях реализации модели. То, что я могу сделать, это хранить пары ключ/значение во внешнем файле конфигурации, который будет использоваться моделью для определения используемого движка.

Поделиться
  • 0
    так вы говорите, пойти по маршруту IoC? Что-то должно создать экземпляр механизма хранения. Если да, есть ли у вас какие-либо предложения по использованию фреймворков или фрагментов кода? Или доморощенный?
  • 0
    Да, это в значительной степени та же самая реализация, которую использует SQLAlchemy, и она довольно эффективна.
Показать ещё 10 комментариев
2

Вы собираетесь создать еще один слой ORM.

Вместо того, чтобы тратить много времени на изобретательство этого колеса, узнать о существующих ORM и адаптировать его к вашему движку базы данных noSQL.

Начните, например, с SQLAlchemy как ORM, который может выполнять все то, что вы хотите (и многое другое) для SQL.

Из-за написания утиной Python вы можете придумать совместимый ORS ORM ORS или ORS-репозиторий или что-нибудь еще, что вы считаете важным.

Однако не изобретайте это колесо с нуля. Прочтите несколько других реализаций. SQLObject, Django ORM, SQLAlchemy - хорошие места для начала.

Поделиться
  • 1
    @dre: «Я бы не использовал истинную силу орма». Ложь. Вы уже используете эту силу. «Избыточность» - это то, что каждый говорит, чтобы оправдать написание еще одной копии существующего фреймворка. "Прочитайте несколько других реализаций". Пожалуйста.
  • 1
    @dre: "не каждое написанное приложение требует использования orm." Какая? Я не утверждаю, что все приложения нуждаются в ORM. Я утверждаю, что ваши требования - это ORM, и вы должны очень внимательно прочитать как минимум три существующих ORM, прежде чем делать что-то другое. «Написание новых рамок - пустая трата времени». Это часто так. Это «привлекательная неприятность», как говорят юристы. Пожалуйста, прочитайте, по крайней мере, три другие реализации. Пожалуйста.
Показать ещё 6 комментариев
0

Это практичное решение, я сделал аналогичные вещи в других проектах. Убедитесь, что вы сохраняете всю реализацию базы данных в классах базы данных. main должен иметь возможность переключаться между ними без каких-либо изменений. Если вам нужно внести изменения в main при переключении, это, вероятно, код, который должен быть в классах Sql.

Я бы сделал Repository базовым классом, из которого получаются другие, а не с оберткой. Таким образом, если две реализации имеют идентичный или очень похожий код, вы можете перемещать части в репозиторий, чтобы не дублировать его.

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню