Рекомендации по 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).

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

Answer 2

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

Service Layer = слой между презентацией и бизнес-слоем.

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

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

вопросы безопасности

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

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