Вот архитектурная проблема при использовании Dao, Service и Controller:
Предположим, что: На уровне DAO есть классы DAO, называемые: Dao1, Dao2, ...
На уровне обслуживания есть классы обслуживания, называемые: Service1, Service2,...
На уровне контроллера есть классы контроллеров, называемые: Controller1, Controller2,...
Service1 необходимо внедрить Dao1, а Сервис2
Controller1 необходимо внедрить Dao2, Service1 и Контроллер2
Соответствует ли эта архитектура принципам JEE? Есть ли проблема?
Лучше сказать, что: Сервис может внедрять только Дао, а Контроллер может внедрять только Сервис?
Насколько я понимаю, JEE не упоминает/рекомендует шаблоны проектирования. JEE определяет набор API-интерфейсов в различных областях, таких как транзакции, jdbc, jax-rs и т. д., а реализация этих API предоставляется разными поставщиками. Таким образом, стандарты JEE помогают разрабатывать корпоративные приложения, но не диктуют никаких принципов проектирования. Поэтому я предполагаю, что ваш вопрос заключается в том, соответствует ли эта архитектура хорошим шаблонам проектирования и есть ли какие-либо проблемы.
В идеале, согласно вашему второму вопросу, контроллер не должен вводить класс дао. Контроллер должен вызывать только службы, а службы должны внедрять классы dao и вызывать их методы. Этот дизайн обеспечивает слабую связь между уровнями контроллера, сервиса и dao. Таким образом, если сигнатура метода класса dao изменяется, уровень контроллера остается нетронутым, и необходимо изменить только уровень обслуживания.
Вообще говоря, большинство проектов стараются достичь максимально возможной слабой связанности и высокого сцепления.
Надеюсь это поможет!