2013-07-14 5 views
2

давайте подумаем о простой операции с пользователем. Мои классы, связанные с весной, чтобы сделать это задание: UserController, UserService, UserServiceImpl, UserDAO, UserDAOImpl.Какова наилучшая практика для шаблона service-dao?

На стороне контроллера я звоню userService.insert(new User()) и в userService.insert() метод я звоню userDAO.insert(user). Я думаю, что существует дублирование метода по этой схеме.

Есть ли способ избежать дублирования методов? Может быть, моя кодировка неисправна. Я жду ваших ответов, опыт ...

благодарственное заранее ...

ответ

0

что вы обрисовал в общих чертах выглядит хорошо и подходит много реализаций шаблона бизнес-услуг. что может вызвать у вас путаницу, так это то, что обычно язык описания метода/функции различается между каждым слоем. например, «insert» - это более длительный срок хранения данных, тогда как уровень «бизнес/сервис» хочет «создать» пользователя. Причина разницы есть обычно разница в понятиях. «создание» пользователя на уровне сервиса - это всего лишь один «объект», «пользователь», тогда как на уровне DAO это на самом деле пара шагов; 1. создайте «пользователь», 2. создайте свой «адрес» в другой таблице, 3. добавьте их в любые группы безопасности.

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

+0

да некоторые методы обслуживания существуют различные шаги DAO взаимодействия, но% 70 моих методов обслуживания есть только одна линия что-то вроде xDAO.saveOrUpdate() или xDAO. delete() и т. д. Поэтому я спрашиваю себя, почему я не использую непосредственно методы DAO при использовании этих методов% 70. Как вы думаете? – user1153321

+0

Прямое воздействие базового DAO (скажем, прямого вызова от контроллера) не обязательно является плохим.это зависит от вашего варианта использования, сложности приложения и вашего «будущего» плана. лично я люблю абстракцию слоя «службы» в середине, поскольку это дает мне комнату, чтобы «вырасти» в будущем (выполнять больше операций, чем просто направление DAO) и поддержку проверяемость и т.д., это может быть столь же спорно, как интерфейс > Аргумент реализации ", если я никогда не буду делать больше, чем x, зачем создавать интерфейс?" –

1

Я думаю, что это не дублирование, я думаю, вы использовали очень плохие имена (которые делают его похожим на дублирование).

Сервисный метод «создает» пользователя, а метод DAO «вставляет» или «сохраняет» его.

И теперь вы видите, что «создавать» и «вставлять» - это два разных действия с различными областями и разным уровнем абстракции. Так что это не дублирование.

+0

- единственное проблемное имя методов? Давайте подумаем, что это ... X entity имеет только 2 поля; id, name и нам нужны простые экраны CRUD. При поддержке вам нужно только сохранить, обновить, удалить, запросить X Entity. Для этой цели, если я использую XService и XDAO, XService будет только имитировать/дублировать методы XDAO, правильно? – user1153321

+0

проблема не в самом имени, проблема в том, что делают методы (ы): в вашем случае метод службы создает сущность, а метод DAO ее сохраняет - это две связанные, но разные вещи. – Ralph

0

Структура, которую вы описываете, помимо замешательства имени, является хорошей отправной точкой. В зависимости от сложности вы можете просто покинуть классы интерфейса, и в итоге вы получите три класса. Если ваше приложение мало (для среднего), я считаю это законным подходом, даже если это не лучшая практика. Знакомство с интерфейсом, как только вы обнаружите, есть много зависимостей, и вам нужен какой-то пакет api для части вашего приложения, которую легко представить с весной, пока это не все приложение.

Еще одна вещь, о которой вы должны помнить, заключается в том, что вам не нужно умножать эту целую цепочку классов для каждого использования. Обобщенный SimpleCrudDao и SimpleEntityService отлично справляются. Затем, как только этого SimpleEntityService недостаточно, вы можете приступить к созданию специфических объектов, таких как UserService, которые имеют createUserAndTransferEntitiesAndUpdateКакие методы.

+0

Фактически я использую ваше решение; с SimpleEntityService Я делаю свои простые операции CRUD на стороне контроллера, и если мне нужно n-шаговое решение, я создам специальную службу. Я просто хотел быть уверенным, было ли это законно :) Спасибо за ваш ответ. – user1153321

2

Для моих проектов я использую эти сервисные и DAO-уровни. Я не знаю, что это лучшая практика или нет.

Это пример создания уровней операции:

[View Layer] 
    * Simple HTML form or AJAX request 
     | 
     | User submits create form. Browser sends POST data 
     | to controller. 
     | 
[User Controller] 
    * Authentication and authorization. @Security annotations can be for method security. 
    * Controller tries to bind POST data to UserCreateForm. If can't Validation exception occurs. 
    * Validates bind data according to validation annotations. @Required ... 
     | 
     | (UserCreateForm) is POJO class which has validation annotations. 
     | It is similar but different from domain objects. 
     | 
[User Controller] 
    * Logs errors via Logging API (logback, slf4j, log4j ...) 
    * Copies form values from UserCreateForm to User domain object 
    * Calls service methods. 
    * Passes messages and model objects to desired view page. 
     | 
     | (User) is POJO class. called domain object, contains ORM annotations if using JPA 
     | or hibernate. It is similar but different from form/command objects. It can be 
     | generated automatically by tools (IDE, hibernate tools ...) 
     | 
[UserService & UserServiceImpl] 
    * Calls multiple DAO methods in one transaction. If an error occurs. rolls back. 
    * Contains business logic 
    * Doesn't know the database technology. 
     | 
     | (User) domain object. 
     | 
[UserDAO & HibernateUserDAOImpl || JpaUserDAOImpl || OracleJdbcDAOImpl ...] 
    * DAO layer knows the persistence technology 
    * Operations are atomic 
Смежные вопросы