Правильно ли получить доступ к слою DAO из уровня контроллера?
в моих приложениях я обычно к DAO layer для получения / сохранения или обновления объектов в репозитории, и я использую сервис layer для выполнения более сложных операций.
поэтому мой вопрос таков: правильно ли (в соответствии с лучшими практиками и шаблонами дизайна/архитектуры) получить доступ к DAO слой контроллер слой, или я должен обойти его через сервис слой? Спасибо!
4 ответов
теоретически: в контексте архитектурного шаблона MVC нет четкого различия между уровнем доступа к данным (DAO) и уровнем обслуживания. Слой сервиса и слой DAO можно рассматривать как "модель" в MVC. Уровень сервиса вполне может реализовать бизнес-логику, сложные проверки и т. д. - это все-таки слой для доступа к вашим данным! Пока вы поддерживаете четкое разделение проблем между объектами модели, представления и контроллера, было бы правильно получить доступ слой DAO из объекта контроллера.
на практике: я видел оба сценария. Если у вас есть небольшое приложение с простой моделью данных, имеет смысл использовать слой DAO непосредственно из контроллеров. Однако, поскольку бизнес-логика усложняется, или если ваша модель используется более чем одним приложением, было бы разумнее исключить бизнес-делегатов и DAOs, чтобы повторно использовать компоненты, минимизировать влияние при внесении изменений, повысить гибкость между компоненты и т. д. Это будет продиктовано технической архитектуры системы.
Я думаю, что если нет необходимости в какой-либо обработке с уровня сервиса, нет проблем с тем, чтобы иметь уровень контроллера для прямого доступа к DAO. Но он действительно должен иметь хотя бы какую-то обработку, например, сервер valitadion входных данных, прежде чем возиться с базой данных.
вы должны обойти его на уровень обслуживания.
причины для этого:
- позже вы можете поместить управление транзакциями в этот уровень сервиса.
- в случае, если вы хотите полностью изменить уровень контроллера на другой фреймворк ( например, изменить стойки на Spring MVC), если вы поместите весь код, вызывающий DAO в сервис, его легче рефакторировать ( вам нужно только Spring MVC для вызова существующей службы). Представьте, если вам нужно поставить все DAO вызов вашего слоя Spring MVC.
думаю, я здесь иконоборец. Я согласен с ответами, приведенными до сих пор, которые говорят, что обход уровня обслуживания прекрасен в принципе, но по моему скромному мнению, это не на практике.
основная причина в том, что трудно предвидеть, когда бизнес-логика может быть когда-нибудь введена. Например, я считаю "ведение журнала" бизнес-логикой. Если я хочу ввести ведение журнала или ведение журнала или ограничить доступ, я не хочу этого делать это на уровне DAO. Но если у меня есть код, который обходит слой DAO, теперь все, что код должен быть переработан.
есть еще одно преимущество слоя DAO, которое я часто находил полезным. Есть операции, которые я могу захотеть предоставить слою сервиса, но не любому слою над ним.
в качестве примера я могу представить слой DAO, который возвращает зашифрованные пароли, но уровень сервиса, который позволяет только сказать, соответствует ли зашифрованный пароль, который вы передаете в базе данных. Я не хочу, чтобы уровень контроллера мог получать действительные зашифрованные пароли - я вижу, что ненужная экспозиция.
таким образом, хотя я могу согласиться, что если вы знаете наверняка, вам никогда не понадобится вводить бизнес-логику (например, как я описал), и если у вас нет необходимости скрывать некоторые операции доступа к данным, подвергая другие... затем непременно подвергните слой DAO более высоким слоям.
моя точка зрения заключается в том, что на практике вы не можете "знать" это, и вы не должны предполагать этого.