Связь между разными частями модулей / комплектов приложения для максимальной развязки?
Я стараюсь сделать свое приложение максимально гибким, отделенным, насколько это возможно.
Я буду разбивать приложение на разные пакеты, которые будут выполнять четкие обязанности.
Теперь о моей главной заботе: как мне сделать так, чтобы два или более пакета обменивались информацией друг с другом?
Я изучал различные парадигмы, такие как безголовая CMS, архитектура микросервисов и т. Д., Которые вдохновляли меня.
Допустим, у меня есть UserBundle, который обрабатывает регистрацию и вход в систему пользователей. Тогда у меня есть еще одна связка, DashboardBundle. DashboardBundle отвечает не за управление пользователями, но для этого необходимо отображать сообщение «Hello John Doe» в верхней части строки меню.
Решения, которые я до сих пор думал:
-
Один из способов решения этой проблемы заключается в том, что каждый пакет может обеспечить свой собственный API. Это означает, что пакет панели инструментов будет просто вызывать API-интерфейс API UserBundles, запрашивая текущего зарегистрированного пользователя.
-
UserBundle будет предоставлять сервис UserManager или что-то подобное, то есть слой между UserBundle и любым другим Bundle / Code, нуждающимся в связи с UserBundle.
Два первых решения по-прежнему будут объединяться в пакеты, НО они могут разрабатываться совершенно независимо, хотя DashboardBundle, очевидно, зависит от UserBundle.
Действительно ли это глупо, если я хочу добиться развязки, или это действительно правильный подход? Если это на самом деле не сумасшедшие идеи, есть ли у кого-нибудь названия концепций, которые называются так, чтобы я мог углубиться в эту идею?
Решение
вы найдете ответ Вот Используемые концепции шаблонов проектирования — хорошее решение для развязки / сцепления и других проблем. Но приятно не преувеличивать и не усложнять ваше приложение.
Другие решения
Все в модульной системе должно быть независимым. Symfony использовал EventDispatcher для этой работы. Если вы создаете событие в Javascript, то вы вызываете это событие в другом модуле (Bundle). С помощью Eventdispatcher вы можете создать структуру, подобную системе подключений WordPress. Вы можете использовать KnpMenuBundle для меню. С EventDispatcher вы можете добавлять меню из разных пакетов.
ИМХО ты смешиваешь понятия. Части вашего приложения должны быть повторно используемыми (например, диспетчер пользователей, подключение к внешним службам и т. Д.), Которые должны быть пакетами. Затем, когда они представляют собой пакеты, вы решаете загрузить их как поставщика или как пакеты. Но основная часть вашего приложения должна быть в AppBundle, потому что эта часть должна быть наиболее специфичной для вашего приложения и по этой причине менее многократно используемым кодом.
Поэтому я хотел бы сделать самые общие части ваших пакетов приложений (или повторно использовать существующие пакеты), а затем создать единый пакет приложений с конкретным кодом приложения.
Общие части вводятся в ваш AppBundle в виде сервисов или наследования (то есть для определения сущности), а ваша конкретная часть кода отвечает за знание того, как разговаривать с поставщиками или другими пакетами.
detector