Архитектура Entities в Doctrine, Symfony 4 — кто может помочь?

Всем привет,
Есть три проекта в корне похоже друг на друга.
По крайней мере некоторые entity. Как бы построить Архитектуру чтобы можно было использовать эти entity во всех проектах.
Было несколько идей:
1. Использовать Traits, но это как-то не то.
2. Создать abstract Class и наследовать, но есть одно но, наследовать можно только оди раз... проэктэ всё же чуть-чуть отличаются. Кое-где нужна relation а где нет. Или кое-где relation m:n и кое-где наоборот.
Подскажите как вы делаете в этих ситуациях?
  • Вопрос задан
  • 273 просмотра
Пригласить эксперта
Ответы на вопрос 1
ghost404
@ghost404
PHP Developer
Есть такая штука как предметная область (Domain). Предметная область состоит из моделей (в Doctrine это Entity), сервисов предметной области и много чего ещё.

На сколько я понимаю из ваших комментариев, у вас есть 3 интерфейса (UI) которые работают с единой предметной областью. В этом случае не нужно дублировать бизнес-логику под каждый интерфейс. Правильней выделить бизнес-логику в отдельный субъект и реиспользовать его в ваших приложениях с интерфейсами.
Можно организовать код вашей бизнес-логики в самостоятельный модуль, вынести в пакете Composer и оформить как Symfony Bundle, что вы и сделали.

Если же у вас есть несколько независемых проектов/сайтов у которых схожая предметная область с небольшими отличиями, то я рекомендую не использовать одну реализацию бизнес-логики на все проекты и рекомендую продублировать код во все проекты.
Поясню. Поначалу, на маленьких проектах кажется хорошей идеей реиспользовать код, но со временем проекты развиваются и развиваются они как правило независимо друг от друга. С развитием отдельных проектов может, и скорей всего будет, изменяться бизнес-логика соответствующих проектов и вам придется вносить изменения в единый код для всех проектов. Таким образом изменения будут применяться не только в том проекте где они нужны, но и в других проектах которым эти изменения не требуются. Это может нарушать бизнес-логику других проектов, приводить к конфликтам и неожиданным ошибкам. Этот подход имеет право на жизнь, но нужно оценивать риски и всё тщательно взвешивать. Моя практика показала, что ни к чему хорошему это не приводит.
Ответ написан
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы