is this Service layer violating SRP principle

Question

I am developing a Web App in Spring and hibernate. I am loading entities in Database.Authors,books,Publication etc are my entities which are getting loaded from excel. I have mode one Entity Load Service interface and then I have its Implementations for every entity. My Service calls DAO implementations. Now I am struggling to find if the below mentioned code violates SRP. Also I am always confused about how to decide responsibility of the class because any class can have many methods and each method can be performing something different.So should they be separated in different class?.take in my case I have 4 methods each performing different task.So I end up with 4 different class for each method.If I follow this approach(which I know is wrong) then I will always end up in classes having single method. Also,sometimes I feel that I going away from domain driven design because I am refracting the code on the basis of functionality.

Any suggestions on how to decide what the responsibility is from the perspective a class? SRP stands for single responsibility principle.And I am really confused in identifying this responsibility.

public interface EntitiesLoadService {

    public void loadEntities(Object o);
    public  void deleteEntities(Object o);
public List getEntities();
public Object getEntity(Object o);

}

Service Implementation

@Service("authorLoadService")
@Transactional
public class AuthorEntityLoadService implements EntitiesLoadService{

    private AuthorDAO authorDao;





    @Autowired
    @Qualifier("authorDAO")
    public void setAuthorDao(AuthorDAO authorDao) {
        this.authorDao = authorDao;
    }

    @Override
    public void deleteEntities(Object o) {
        // TODO Auto-generated method stub

    }

    @Override
    public void loadEntities(Object o) {
        Set<author_pojo> author=(Set<author_pojo>)o;
        Iterator<author_pojo> itr=author.iterator();

        while (itr.hasNext()) {
            author_pojo authorPojo = (author_pojo) itr.next();
            authorDao.save(authorPojo);

        }


    }

    @Override
    @Transactional(readOnly=true)
    public List getEntities() {
        // TODO Auto-generated method stub
        return null;
    }

    @Override
    @Transactional(readOnly=true)
    public Object getEntity(Object o) {
        String author=(String)o;
    author_pojo fetAuthor=authorDao.findOneByName(author);

        return fetAuthor;
    }

}

Answer 1

You have AuthorDAO which is the class that should be doing all interactions with the persistence layer, ex. a database.

It isn't obvious in your example because your AuthorEntityLoadService has similar methods which just delegate to the DAO layer.

As your project and requirements grow, you will see that more methods are required for this class. These methods will be responsible for doing more than just CRUD operations on the DAO layer. They might need to interact with other services, internal or external. They might need to do multiple DAO calls.

The Single Responsibility in this case is to provide services for interacting with AuthorEntity instances.

It is on of many correct ways of implementing what you are proposing.

---

More specifically, my opinion on

Also I am always confused about how to decide responsibility of the class because any class can have many methods and each method can be performing something different.So should they be separated in different class?

Just because you have many methods doing different things, doesn't mean the responsibility isn't shared. AuthorEntityLoadService which I would just call AuthorEntityService manages AuthorEntity instances at the service layer. Image if you had one Class with one method for each of create, update, retrieve, delete an AuthorEntity. That wouldn't make much sense.

And on

Any suggestions on how to decide what the responsibility is from the perspective a class?

As further reading, try http://java.dzone.com/articles/defining-class-responsibility

Answer 2

Typically, in this type of n-tier architecture, your service layer is meant to provide an API of transactional (or otherwise resource-dependent) operations. The implementation of each service can use whatever resource-specific dependencies (like DAOs for a particular datasource) it needs, but it allows the service consumer to remain agnostic of these specific dependencies or resources.

So even if your service is just delegating to its resource-specific dependencies, it doesn't violate SRP because its responsibility is to define a resource-agnostic API (so that the consumer doesn't need to know all the resource-specific stuff) that specifies atomic operations (transactional if necessary).