5

let's think about a simple User insert operation. My Spring related classes to do this job are UserController, UserService, UserServiceImpl, UserDAO, UserDAOImpl.

At controller side i call userService.insert(new User()) and in userService.insert() method i call userDAO.insert(user). I think there is a method duplication at this pattern.

Is there a way to avoid method duplication? May be my coding is faulty. I wait your replies, experiences...

Thank in advance...

Benoit Wickramarachi
  • 6,096
  • 5
  • 36
  • 46
user1153321
  • 347
  • 6
  • 18

4 Answers4

4

For my projects i use these service and DAO layers. I don't know it's a best practice or not.

This is a sample create operation levels:

[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
Fırat Küçük
  • 5,613
  • 2
  • 50
  • 53
1

I think it is no duplication, I think you used very bad names (that make it look like a duplication).

The Service Method "create" a user, and the DAO method "insert" or "save" it.

And now you see that "create" and "insert" are two different actions, with different scopes and different level of abstraction. So it is no duplication.

Ralph
  • 118,862
  • 56
  • 287
  • 383
  • is the only problem name of the methods? Let's think this... X entity has only 2 fields; id, name and we need simple CRUD screens. At backed you only need to save, update, delete, query X Entity. For this purpose if i use XService and XDAO, XService will only mimic/duplicate XDAO methods, right? – user1153321 Jul 14 '13 at 20:50
  • the problem in not the name itselfe, the problem is what the method(s) do: in your case the service method create an entity and the DAO method save it - this are two related but different things. – Ralph Jul 14 '13 at 21:42
0

what you've outlined looks fine and fits a lot of implementations of the business service pattern. what may be causing you confusion is that generally the language to describe the method/function differs between each layer. for instance, 'insert' is a more data persistence term, whereas the business/service layer wants to "create" a user. the reason the difference is there is usually a difference in the concepts. "creating" a user at the service layer is just one 'object', a 'user', whereas at the DAO layer, it's actually a couple of steps; 1. create the 'user', 2. create their 'address' in a different table, 3. add them to any security groups.

so in your case you may actually have a 1-to-1, in a lot of cases, the business layers 1 equates to many DAO interactions.

incomplete-co.de
  • 2,137
  • 18
  • 23
  • yeah at some service methods there are different DAO interaction steps but %70 of my service methods have just one line something like xDAO.saveOrUpdate() or xDAO.delete(), etc... So i ask myself why i don't use directly DAO methods at that %70 service methods. What do you think? – user1153321 Jul 14 '13 at 20:44
  • direct exposure of the underlying DAO (say, direct invocation from the Controller) is not necessarily a bad thing. it depends on your use case, complexity of the application and your 'future' plan. personally, i like the abstraction of a 'service' layer in the middle as it gives me room to 'grow' in the future (perform more operations than just the direction DAO) and support testability etc. this can be as arguable as the Interface > Implementation argument, "if i'm never going to do more than x, why create an interface?" – incomplete-co.de Jul 14 '13 at 22:06
0

The structure you describe is, apart the mentionend name confusion, a good starting point. Depending on the complexity you can just leave the interface classes out and you end up with three classes. If your application is small (to medium) i consider this a legit approach even if it is not best practice. Introducing an interface once you discover there are alot of dependencies and you need some kind of api package for a part of you app is easy to introduce with spring as long its not the whole app.

One other thing you have to keep in mind is that you do not need to multiply this complete chain of classes for each usecase. A generalized SimpleCrudDao and SimpleEntityService is perfectly fine. Then once this SimpleEntityService is not enough you can start creating specifc ones like a UserService that has createUserAndTransferEntitiesAndUpdateWhatsoever methods.

Martin Frey
  • 10,025
  • 4
  • 25
  • 30
  • actually i use your solution; with a SimpleEntityService i do my simple CRUD operations at controller side and if i need a n step solution i create a special Service. I just wanted to be sure if it was legal:) Thanks for your answer. – user1153321 Jul 15 '13 at 06:31