Я хотел бы следовать принципу дизайна separation of concerns в новом веб-приложении Java EE. Если я правильно понимаю, это означает, что я должен сохранить технический выбор моего DAL (уровня доступа к данным), невидимый для моего модельного/бизнес-уровня.Многоуровневая архитектура и постоянные аннотации на бобы модели?
Как я использую Spring Data Neo4j, я должен аннотировать мои модельные бобы, например. «@NodeEntity», аннотация, которая относится к Spring Data Neo4J. Кажется, что это сочетание уровня модели с уровнем доступа к данным.
- Является ли это хорошим анализом, который я здесь делаю?
- Если да, то как я могу создать модель, которая не зависит от моего DAL, используя аннотации Spring Data Neo4j?
Благодарим за помощь!
интерфейс DAO имеет то же назначение интерфейсов сущностей, создать уровень абстракции между моделью и уровень доступа к данным. Использование GraphRepository напрямую нарушает эту абстракцию, подвергая SDN слою модели. – remigio
Спасибо за идею интерфейсов, но у меня все еще есть вопрос. В настоящий момент для каждого модельного класса, например, «Пользователь», я создал интерфейс «UserRepository», который расширяет GraphRepository. Нужно ли мне создавать новый интерфейс UserDAO, или это то же самое, что интерфейс UserRepository? Другими словами, насколько стандартным является интерфейс GraphRepository Spring Data Neo4j? –
Хорошо, спасибо, думаю, теперь я понимаю. –