0

I've seen service classes that do nothing except forwarding calls to DAO classes. E.g. userService.save(user) would simply call userDao.save(user)

I heard the argument that some day in the future, a service class may do a bit of extra lifting and call more than one DAO. Also, any DTO to entity mapping should also be at the service layer (and not in the controller)

However, in my current project, a desktop Swing application, we don't have any of that. Instead, we have some unseemly hybrids of entity and DAO that store the data (in public fields) and persist it as well. E.g. the DEPARTMENT class matches the DEPARTMENT DB table and both stores the values of the associated table row and communicates with the DB. So, for example, updating the table data may look something like this

new DEPARTMENT().setId(id).setName(newName).UPDATE();

Such classes should obviously be split into at least entity and DAO classes

But should we add another, service layer that would (I guess) only forward to DAO classes and nothing else?

Our table count is great, and few people know the real number. But it's in the thousands

Improve this question
1
  • I've worked in four projects, where the largest problem was lack of separation between persistence layer and business logic. Never again! Commented Aug 9, 2024 at 14:01

2 Answers 2

Reset to default
1

new DEPARTMENT().setId(id).setName(newName).UPDATE(); it is an active record design pattern implementation that it is equivalent to "service classes that only forward to DAO".

The service component of an application implements the requirements of a certain type of business, what it isn't in the service component does not belong to the business that's why the service component uses abstractions (e.g. DAO for persistence environment) to leverage the plug-in, add-on of the business support components. When an abstraction's implementation changes everything that it is in the replaced implementation without a correspondent in the service component is irrelevant for the business (e.g. nice to haves, local enhancements).

Use the service component to centralise the business knowledge with the advantage of being able to switch to different implementations that improves independently of the business and once plugged-in improves the business, mostly its efficiency.

Use all application's components to implement the business knowledge with the advantage of having custom business specific local enhancements.

Improve this answer
0

This way you are separating the responsibilities between several layers and by wrapping DAO methods by Service - think the access to DB is business logic as well, even doe there are no complex rules.

Improve this answer
1
  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. Commented Aug 11, 2024 at 2:08

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.