2015-08-19 3 views
0

Я хочу знать использование классов обслуживания в J2EE.Почему мы используем классы обслуживания в интеграции весной спящего режима

У меня есть 2 проекта.

Один из них связан с интеграцией с весной зимой. Этот проект содержит DAO, MODEL, SERVICE и CONTROLLER. Ввиду того, что запрос является доступом контроллера и отправляет значения в класс dao через класс обслуживания.

2-й проект содержит только классы BEAN, CONTROLLER и DERIVED. Ввиду того, что запрос является доступом контроллера и отправляет значения непосредственно производному классу. Query записывается в этот производный класс.

Я хочу знать разницу между этими двумя проектами. Почему мы используем класс обслуживания?

+0

Это архитектурные различия и могут быть выбраны в соответствии с вашими требованиями. Например, узнайте больше о MVC, если хотите узнать больше о архитектуре контроллера модального представления. Однако просто эти «слоистые архитектуры» были построены на основе их обязанностей. DAO, Modal's, Service и Controller имеют разные обязанности. – SerhatCan

+1

Редактировать улучшает возможность чтения. Теперь вопрос будет легко прочитан –

ответ

2

в моем опыте, класс обслуживания содержит все бизнес, вычислять, логику , например, в модуле авторизации: база на MVC шаблон класса модели (DAO, модель является моделью вызова): Пользователь, UserDAO Контроллер: UserController Просмотр : LoginPage Это не значит, что мы не можем создать другой класс, такой как Service , у нас может быть класс UserBusinessthis, содержащий весь метод, логика, используемая для пользователя, такая как validateUserLogin ... и т. Д. приложение может работать как: Пользовательский доступ LoginPageinput value и submit => UserController => UserBusiness => UserDAO нам нужно делить на удобную ручку и поддерживатьВесной мы аннотацию, как

@Business 
@Repository 
@Controller 

, который производитель пружины создаст объект, мы нет необходимости в использовании «нового» ключевое слово.

+0

Большое спасибо за ответ. :) –

2

Контроллеров: используется только делегирование вызовов, то есть когда-то просьба прийти на контроллере он направит его к относительной службе

Услуги: Услуги будут развиваться, чтобы написать бизнес-логику в целом.

Dao: Данные объекта передачи, которые намерены иметь дело с DTO-х

Итак, кратко, когда Spring MVC получить вызов. Я передам контроллеру, контроллер, чем перенаправляет его на соответствующий сервис. Служба выполняет бизнес-логин, если таковой имеется в вызове api, и делегированное обновление данных для уровня DAO.

+0

Есть ли какие-либо преимущества в использовании класса обслуживания? –

+0

Преимущество здесь заключается в четком разделении между всеми слоями. Если нет уровня обслуживания, вам необходимо записать бизнес-логику либо на уровне контроллера, либо на уровне DAO. что не является правильным способом для этого. Мы должны иметь четкое разделение между ролями и обязанностями разных слоев. – Jaydatt

+0

@GayathriRajan, цель службы - написать свою бизнес-логику, вот что говорит Jaydatt. Например, у вас есть приложение калькулятора, тогда контроллер просто выберет значения от пользователя, где, поскольку служба будет выполнять фактическую логику, например, сложение, вычитание и т. Д. – Chaitanya

Смежные вопросы