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