Но это глобальное состояние и оно одно на все приложение. С помощью него мы создаём сессию и при помощи репозиториев можем ее реализовывать.
Нам его достаточно одного и мы его можем инжектить во все реализации репозиториев и опять таки класс нам необязательно создавать для этого)
И SQL - это язык запросов. Если мы в сервисах меняем какую-либо сущность, это же не значит, что у нас в том же сервисе есть состояние. Состояние есть у модели, но не у сервиса.
Чувствую, что дискусия заходит в тупик, я учту Ваши доводы и постараюсь провести более корректное сравнение подходов на примере полной реализации веб-приложения в следующе й статье ?
Нет, в SomeRepository будет подключение к БД, а в подключении конкретный логин/пароль, или идентификатор сокета, или другие параметры, которые обеспечивают соединение с БД
Параметры у баз данных могут отличаться и им не место в репозитории, который у нас stateless и наличие sql в реализации это не показатель наличия состояния)
Правильные вопросы задаёте) Касаемо разделения интерфейсов, по-хорошему нужно для каждого метода делать свой протокол и потом с помощью композиции создавать общий. Статья хорошая, спасибо за рекомендацию. Но я все-равно считаю, что использование общего репозитория не самая плохая практика и в том же spring-data очень часто используется. Протоколы лежат отдельно, здесь как мне видится больше дело вкуса, хотя скорее всего было бы да, логичнее их держать вместе.
Подключение к БД - это подключение к БД)) Не нужно смешивать конфигурацию и логику работы с базой данных. Изменение типа хранение не должно затрагивать изменение интерфейса взаимодействия с SomeService, а в вашей ситуации это скорее всего произойдет. Тажке отдельно прописывается миграция, если нужно.
Верно Вы все пишите, но это игрушечный пример с животными, примитивным наследованием и упрощенной логикой) Моя цель в этом примере разобрать случай выноса логики, а не написать идеальные классы... Насчет docstring аналогичная история. В примере их нет, так как они избыточны, но никто не говорит, что их не может быть)
Во-первых, это моя первая статья здесь и я явно могу ошибиться только первый раз)) В остальных моментах я могу с вами согласиться, здесь как раз-таки и показывается необязательность данных действий. И на счёт четвертого пункта, да, можно не наследовать, однако в таком варианте не лучшим образом подхватывается документация в реализации и возможно другие моменты. Мне хотелось написать аналогично джава-стилю, чтобы продемонстрировать избыточность.
Экземпляр SomeRepository это и есть state для SomeService.
SomeRepository тоже будет stateless, наше состояние - это как правило база данных, либо просто файлы. SomeRepository нужен лишь для того, чтобы вынести логику работы с базой/файлами.
Я не специалист в Python, но вот тут описывают внедрение зависимостей такое же, как в других языках.
Можно использовать классы и внедрять зависимости схожим с другими языками образом. Я лишь хотел показать способ, где можно это дело упростить средствами того же python, без лишних библиотек или еще чего)
подставить мок, который к базе не обращается?
Очень просто на самом деле. Мы спокойно можем замокать любой объект и в python модуль то же объект) + у нас нет проблем той же java, где только сейчас появляются способы замокать статические методы и различные другие конструкции.
Класс SomeService скорее всего stateless. В него нужно будет внедрить SomeRepository, либо-же другие сервисы, с написанием конструктора и созданием объекта это уже 4 строки. Далее, у нас нет встроенного менеджера бинов как в том же Spring Java, поэтому мы должны самостоятельно управлять нашими объектами SomeService. Захотел синглтон(что вполне логично), пиши костыль рода:
some_service = SomeService()
del SomeService
А это еще самый короткий и простой способ и тот будет уже антипаттерном) Итого, плюс 5-10 строк на каждый сервис в лучшем случае.
Также учтём усложнение восприятия управлением этого всего, добавление лишних 4 пробелов каждый раз для методов и получим, что в тех же сервисах можно писать без класса.
Поскольку во множестве случаев они избыточны) Классы могут быть полезны при группировке поведения и свойств в одном компоненте. Но в случае stateless приложений, коими серверные приложения во многом являются, мы можем использовать модули. Это будет проще для восприятия и удобнее для использования.
Верное замечание. В данном примере лучше сделать именно так, либо вообще убрать внедрение экземпляра животного, так как здесь нет изменений состояний объектов или вывода свойств. Однако решение с репозиториями было бы правильнее.
Все ООО очень абстрактно… Если уж принялись, то нужно учитывать и то, что летом люди больше гуляют и взаимодействуют друг с другом, что повышает заразность. Также очень сильно отличаеися кол-во зараженных в одном климатическом поясе. В общем есть много моментов, которые нужно учесть, но я так понял, что суть статьи была именно в том, чтобы выпереть людей на свежий воздух)
Драйвер базы да, он содержит состояние, вы правы.
Но это глобальное состояние и оно одно на все приложение. С помощью него мы создаём сессию и при помощи репозиториев можем ее реализовывать.
Нам его достаточно одного и мы его можем инжектить во все реализации репозиториев и опять таки класс нам необязательно создавать для этого)
И SQL - это язык запросов. Если мы в сервисах меняем какую-либо сущность, это же не значит, что у нас в том же сервисе есть состояние. Состояние есть у модели, но не у сервиса.
Чувствую, что дискусия заходит в тупик, я учту Ваши доводы и постараюсь провести более корректное сравнение подходов на примере полной реализации веб-приложения в следующе й статье ?
Параметры у баз данных могут отличаться и им не место в репозитории, который у нас stateless и наличие sql в реализации это не показатель наличия состояния)
Учту этот момент, будет вовремя добавлю малость логики в пример ?
Тоже верно. Здесь зависит от конкретного случая, поскольку макросервисы также могут появляться)
Правильные вопросы задаёте)
Касаемо разделения интерфейсов, по-хорошему нужно для каждого метода делать свой протокол и потом с помощью композиции создавать общий.
Статья хорошая, спасибо за рекомендацию. Но я все-равно считаю, что использование общего репозитория не самая плохая практика и в том же spring-data очень часто используется.
Протоколы лежат отдельно, здесь как мне видится больше дело вкуса, хотя скорее всего было бы да, логичнее их держать вместе.
Подключение к БД - это подключение к БД))
Не нужно смешивать конфигурацию и логику работы с базой данных. Изменение типа хранение не должно затрагивать изменение интерфейса взаимодействия с SomeService, а в вашей ситуации это скорее всего произойдет. Тажке отдельно прописывается миграция, если нужно.
Верно Вы все пишите, но это игрушечный пример с животными, примитивным наследованием и упрощенной логикой)
Моя цель в этом примере разобрать случай выноса логики, а не написать идеальные классы...
Насчет docstring аналогичная история. В примере их нет, так как они избыточны, но никто не говорит, что их не может быть)
Во-первых, это моя первая статья здесь и я явно могу ошибиться только первый раз))
В остальных моментах я могу с вами согласиться, здесь как раз-таки и показывается необязательность данных действий.
И на счёт четвертого пункта, да, можно не наследовать, однако в таком варианте не лучшим образом подхватывается документация в реализации и возможно другие моменты. Мне хотелось написать аналогично джава-стилю, чтобы продемонстрировать избыточность.
Тестирование очень интересная тема, хотелось бы ее затронуть в следующей статье при полной реализации веб-сервиса.
SomeRepository тоже будет stateless, наше состояние - это как правило база данных, либо просто файлы. SomeRepository нужен лишь для того, чтобы вынести логику работы с базой/файлами.
Можно использовать классы и внедрять зависимости схожим с другими языками образом. Я лишь хотел показать способ, где можно это дело упростить средствами того же python, без лишних библиотек или еще чего)
Очень просто на самом деле. Мы спокойно можем замокать любой объект и в python модуль то же объект)
+ у нас нет проблем той же java, где только сейчас появляются способы замокать статические методы и различные другие конструкции.
Класс SomeService скорее всего stateless. В него нужно будет внедрить SomeRepository, либо-же другие сервисы, с написанием конструктора и созданием объекта это уже 4 строки.
Далее, у нас нет встроенного менеджера бинов как в том же Spring Java, поэтому мы должны самостоятельно управлять нашими объектами SomeService.
Захотел синглтон(что вполне логично), пиши костыль рода:
А это еще самый короткий и простой способ и тот будет уже антипаттерном)
Итого, плюс 5-10 строк на каждый сервис в лучшем случае.
Также учтём усложнение восприятия управлением этого всего, добавление лишних 4 пробелов каждый раз для методов и получим, что в тех же сервисах можно писать без класса.
Поскольку во множестве случаев они избыточны)
Классы могут быть полезны при группировке поведения и свойств в одном компоненте. Но в случае stateless приложений, коими серверные приложения во многом являются, мы можем использовать модули. Это будет проще для восприятия и удобнее для использования.
Верное замечание. В данном примере лучше сделать именно так, либо вообще убрать внедрение экземпляра животного, так как здесь нет изменений состояний объектов или вывода свойств. Однако решение с репозиториями было бы правильнее.
Все ООО очень абстрактно… Если уж принялись, то нужно учитывать и то, что летом люди больше гуляют и взаимодействуют друг с другом, что повышает заразность. Также очень сильно отличаеися кол-во зараженных в одном климатическом поясе. В общем есть много моментов, которые нужно учесть, но я так понял, что суть статьи была именно в том, чтобы выпереть людей на свежий воздух)