Лучшие практики DAO (объект доступа к данным) - примеры, которые я вижу, используют оба объекта DAO и Services, какова здесь лучшая практика?

Question

Я создаю объект доступа к данным для извлечения информации из Google App Engine для веб-приложения, созданного на платформе Spring (впервые для всех).

Я вижу несколько примеров использования шаблона Controller / webapp -> Service -> DAO -> JDO / Google-app-engine.

В этом шаблоне уровень DAO является единственным, который знает о JDO, поэтому этот уровень является единственным, который нуждается в замене, если хранилище данных изменилось. Уровень служб вызывает уровень DAO и форматирует / манипулирует необходимыми данными.

У меня вопрос, почему дополнительный слой сервиса? По крайней мере, вначале не похоже, что уровень сервиса добавляет много к уравнению. Я, естественно, подумал бы просто написать слой DAO для инкапсуляции запросов JDO, манипулирования и возврата данных.

Может ли кто-нибудь показать мне рациональность для отдельного уровня обслуживания, станет ли это очевидным, когда проект станет более масштабным и сложным?

Answer 1

Обычно вы помещаете DAO в сервисный уровень, потому что по мере усложнения приложения вы будете выполнять полезные и нетривиальные действия в сервисе.Например, вы можете координировать сложные операции с данными с более чем 1 DAO.Слои сервисов также предоставляют границы API, которые разграничивают сквозные задачи, такие как управление транзакциями, проверки авторизации, ведение журнала производительности и т. Д.

Еще одна причина, по которой полезно абстрагировать вашу функциональность в сервисы, заключается в том, что она продвигает повторно используемые и обслуживаемые компоненты.Когда вы начнете, вам может быть интересно просто представить немного HTML.Вы пишете сервис, который загружает некоторые данные, и обрабатываете HTML-часть в слое над уровнем сервиса (уровень представления).Теперь вы хотите создать RESTful веб-сервис.Ваш уровень обслуживания может быть повторно использован для загрузки данных;все, о чем вам нужно беспокоиться, это json или xml, который возвращает конечная точка веб-службы (и, конечно, семантика REST).

Таким образом, для простых случаев слой Service может добавить немного, но по мере расширения вашего приложения они становятся стоящимии даже важно для поддержания чистоты кода.

Answer 2

Да, изначально кажется, что уровень обслуживания не добавляет много к уравнению.Но подумайте об этом следующим образом.

Сервисный уровень = слой между вашей презентацией и бизнес-уровнем.

Вы должны знать, что всегда полезно разделять задачи между уровнями.Ваш уровень обслуживания может отображаться в отдельный бизнес-домен, уровни представления, не заботясь о том, как используется ваш уровень DOA.

Вы можете рассматривать это как границу между двумя другими уровнями, в данном случае между презентацией и бизнесом.слои.Код на уровне представления обычно реализует варианты использования.Типичный вариант использования - это последовательность действий, выполняемых пользователем, которые приводят к взаимодействию между одним или несколькими бизнес-объектами, рабочими процессами и сервисами.Уровень обслуживания позволяет абстрагировать эти меньшие взаимодействия с помощью промежуточного API, предоставляемого через более грубые службы.Уровень представления делает один вызов одной службе на уровне.Метод вызванного сервисного уровня будет координировать объекты и рабочие потоки на бизнес-уровне для реализации требуемого поведения.

Проблемы безопасности

1. Я создаю безопасностьслой вокруг служебных стеков.Это поможет мне определить подлинность пользователя и получить доступ к данному сервису.
2. У меня также есть уровень транзакций, определенный вокруг уровня сервиса. Он сообщает ядру базы данных, чтобы фиксировать изменения, сделанные на уровне сервиса, как только онвозвращение после успешных казней.

Эти вещи также должны беспокоить, если вы определяете слои своего приложения.