Задать вопрос

Как организовать проект таким образом чтобы при разработке модулей для него не требовался сам проект?

В проекте на Python пытаюсь выдерживать подход MVC. Проект разросся и добавлять в него функционал для решения специфических задач, стало невыгодно. Решил попробовать добавить возможность создания модулей.
Сделал папку modules и её содержимое импортирую, опираясь на имена вложенных папок. То есть создаёшь папку с определённым именем и через это имя происходит импорт и задействование модуля.
Модуль для своей работы дёргает контроллеры из основного проекта. Доступ к БД также через контроллеры.

Как лучше распространять основной проект, чтоб было удобно писать модули. У меня всё просто, всё в одном репозитории. А как быть если к репозиторию доступа нет, а только урезанная копия проекта?
  • Вопрос задан
  • 768 просмотров
Подписаться 7 Средний Комментировать
Пригласить эксперта
Ответы на вопрос 3
@BorisKorobkov
Web developer
Модуль для своей работы дёргает контроллеры из основного проекта.

Что-то не то с бизнес-логикой. Обычно наоборот, проект использует модуль (мозг дает команду ногам идти, а не ноги управляют мозгом).

Правильнее писать такой модуль, чтобы он не зависел от вашего проекта. Доступ к БД у него должен быть свой. Устанавливать его через requirements.txt

Если модуль нельзя сделать самостоятельным, то тогда хотя бы пусть использует интерфейс, который надо предоставить сторонним разработчикам.
Ответ написан
@ilya_chch
Вы сами себе противоречите:
Как организовать проект таким образом чтобы при разработке модулей для него не требовался сам проект?

Модуль для своей работы дёргает контроллеры из основного проекта.


Получается, что ваш модуль не сможет работать без проекта. Вообще.

Мне кажется, что модули вам стоит делать более мелкими, чтобы они решали только какую-то определенную небольшую задачу.

Посмотрите в сторону того, как устроен механизм Middleware в Django - есть список middleware и запрос последовательно передается в каждый из них, а возвращаемый модифицированный запрос передается в следующий.

По поводу доступа в базу, тоже хороший пример - Django. При инициализации открывается соединение с базой и кладется в некое хранилище конфигураций, откуда можно его взять модулям и использовать. Так, при обособленной разработке модулей, можно будет подложить свое, но в собранном проекте будет использоваться глобальное, что сократит время на открытие соединения.

Для того, чтобы выстроить разработку таких модулей - обозначьте четкий интерфейс каждого типа модуля. Например, модули отвечающий за работу с пользователем, получают на вход объект пользователя и отдают тоже объект пользователя, но либо делают что-то по дороге, либо как-то модифицируют его.
Ответ написан
Комментировать
vladimirbondarev
@vladimirbondarev
Разработчик ПО
Ну здесь на мой взгляд ответ один - это SOLID и clean architecture. Этот подход позволит вам разработать тестируемое и расширяемое приложение.

Например, то что ваше приложение обращается к БД из контроллеров это уже не есть гуд, так как для тестирования бизнес логики вам придется задействовать инфраструктуру, а именно http. По хорошему у вас должен быть слой бизнес логики, который инжектится в контроллер, а в слой бизнес логики должен инжектится, например слой доступа к данным. Таким образом вы можете тестировать любой слой независимо друг от друга, так как у вас будет слабая связанность компонентов системы.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы