Python-сообщество

Всем привет! Такой вопрос.
Писал веб-приложение (Flask) для БД. Стандартный CRUD.
Изначально реализовал (быстро, чтобы скорее запустить) работу с БД через набор классов, описывающих операции с сущностями. Классы получились просто набором статических методов типа:

 class UserRepo:
@staticmethod
def create(data):
#orm работы
@staticmethod
def get_by_id(instance_id):
#orm работы
@staticmethod
def delete(instance_id):
#orm работы

Отредактировано bootcd (Апрель 30, 2024 13:44:19)

А для чего тебе классы-то?

Там нужно сделать класс, в объект которого через конструктор передаётся и агрегируется объект с полиморфными CRUD-методами. В другом языке такой аргумент у конструктора описывается интерфейсом. А дальше нужно делать под каждую базу данных свой класс с CRUD-методами, в объект которого через конструктор передаётся и агрегируется адрес соответствующей базы данных. В итоге ты делаешь такой CRUD-объект под заданную базу данных, к которому привязана база данных, и потом ты делаешь общий CRUD-объект под любую базу данных и добавляешь через конструктор первый объект во второй. А весь клиентский код ты пишешь для этого CRUD-объекта, который с любой базой данных может работать.

  
import sqlite3
 
class Database:
    def __init__(self, db):
        self.db = db
    def read(self):
        return self.db.read()
 
class SQLiteDatabase:
    def __init__(self, filename):
        self.db = sqlite3.connect(filename)
    def read(self):
        result = self.db.execute('select * from tab')
        return result
 
db = Database(SQLiteDatabase('database.sqlite'))
db.read()

Ну прежде всего ты получил какой никакой опыт. Но изобретать свой велосипед - всегда не лучший выбор.
Правильно будет использовать уже готовое решение. Сейчас у тебя куча кастомных запросов и в случае если необходимо внести малейшие изменения в модели или логике тебе все их нужно переписывать а так же дополнительно валидировать данные перед записью обрабатывать ошибки и так далее.
Так что ты подошел к моменту использования ОРМ.
Основной инструмент тут SQLAlchemy - там есть все. Но библиотека довольно таки обширна и нахрапом ее не взять.
Попробуй для начала что нибудь простое для тестов типа peewee
https://docs.peewee-orm.com/en/latest/peewee/quickstart.html#quickstart

Идея в том что ты создаешь модели (Таблицы своей БД) и работаешь с ними как с обьектами не влазя в потроха SQL запросов. И оно уже содержит все выше описанное.
В любом случае Алхимию учить прийдется.

py.user.next
А для чего тебе классы-то?

 server = ServerRepo()
server.data = form_data
server.create()

 server.id = id
server.new_data = form_data
server.update()

Отредактировано bootcd (Май 1, 2024 12:39:11)

ZerG
Ну прежде всего ты получил какой никакой опыт. Но изобретать свой велосипед - всегда не лучший выбор.Правильно будет использовать уже готовое решение. Сейчас у тебя куча кастомных запросов и в случае если необходимо внести малейшие изменения в модели или логике тебе все их нужно переписывать а так же дополнительно валидировать данные перед записью обрабатывать ошибки и так далее.Так что ты подошел к моменту использования ОРМ.Основной инструмент тут SQLAlchemy - там есть все. Но библиотека довольно таки обширна и нахрапом ее не взять. Попробуй для начала что нибудь простое для тестов типа peeweehttps://docs.peewee-orm.com/en/latest/peewee/quickstart.html#quickstartИдея в том что ты создаешь модели (Таблицы своей БД) и работаешь с ними как с обьектами не влазя в потроха SQL запросов. И оно уже содержит все выше описанное. В любом случае Алхимию учить прийдется.

Отредактировано bootcd (Май 1, 2024 12:37:27)

> Сама идея класса из статических методов с одно стороны решает задачу, с другой противоречит принципам ООП.

Почему ты считаешь это проблемой?

> Но почему тогда в любом туториале на эту тему, всегда, практически, все расшивают через классы, цинично игнорируя принципы ООП?

Большая част туториалов написана “дурачками для чебурашек”, по этому не нужно из за них упарываться.

Отредактировано Rodegast (Май 1, 2024 18:17:43)

Rodegast
Почему ты считаешь это проблемой?

Rodegast
Большая част туториалов написана “дурачками для чебурашек”, по этому не нужно из за них упарываться.

> Хочется научиться писать хороший код, за который не стыдно

Хорошо. Как ты отличаешь хороший код от плохого?

> Мне явно не хватает базы понимания проблематики, которую решают паттерны проектирования, так как нет опыта.

У тебя нет высшего образования, по этому и не понятно. Про паттерны, внедрение зависимостей и прочие пока забудь это тебе не поможет.

> Как бы вы решали такую задачу?

То как у меня реализованы операции с БД тебе точно не подойдет. На твоём месте я бы искал аналогичные проекты на github.

bootcd
У каждого класса, делающего такую работу, зачастую, очень разные по сути CRUD методы. ТО есть один такой класс описывает всю возможною работу с сущностью.

bootcd
Хочется научиться писать хороший код, за который не стыдно, который можно будет далее передать другому человеку на поддержку или развитие.

Отредактировано py.user.next (Май 2, 2024 05:10:40)

Rodegast
>Хорошо. Как ты отличаешь хороший код от плохого?

Rodegast
У тебя нет высшего образования, по этому и не понятно. Про паттерны, внедрение зависимостей и прочие пока забудь это тебе не поможет.

Rodegast
То как у меня реализованы операции с БД тебе точно не подойдет. На твоём месте я бы искал аналогичные проекты на github.