Нарушает ли этот Сервисный уровень принцип SRP

Question

Я разрабатываю веб-приложение весной и в спящем режиме. Я загружаю сущности в базу данных. Авторы, книги, публикации и т. Д. Являются моими сущностями, которые загружаются из Excel. У меня есть режим интерфейса Entity Load Service один, а затем у меня есть свои реализации для каждого объекта. Моя служба вызывает реализацию DAO. Сейчас я пытаюсь выяснить, не нарушает ли приведенный ниже код SRP. Также меня всегда смущает вопрос о том, как определить ответственность класса, потому что любой класс может иметь много методов, и каждый метод может выполнять что-то свое. Так должны ли они быть разделены в другом классе? В моем случае у меня есть 4 метода, каждый из которых выполняет свою задачу. Так что в итоге я получаю 4 разных класса для каждого метода. Если я придерживаюсь этого подхода (который, как я знаю, неверен), то я всегда буду в классе с одним методом. Кроме того, иногда я чувствую, что ухожу от доменного дизайна, потому что я преломляю код на основе функциональности.

Любые предложения о том, как решить, какова ответственность с точки зрения класса? SRP выступает за принцип единой ответственности. И я действительно запутался в определении этой ответственности.

public interface EntitiesLoadService {

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

}

Внедрение сервиса

@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

У тебя есть AuthorDAO это класс, который должен делать все взаимодействия со слоем персистентности, напр. база данных.

Это не очевидно в вашем примере, потому что ваш AuthorEntityLoadService имеет похожие методы, которые просто делегируют на уровень DAO.

По мере роста вашего проекта и требований вы увидите, что для этого класса требуется больше методов. Эти методы будут отвечать за выполнение не только операций CRUD на уровне DAO. Им может потребоваться взаимодействие с другими службами, внутренними или внешними. Им может потребоваться сделать несколько вызовов DAO.

Единственная ответственность в этом случае заключается в предоставлении услуг для взаимодействия с AuthorEntity экземпляров.

Это один из многих правильных способов реализации того, что вы предлагаете.

---

Точнее, мое мнение о

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

То, что у вас много методов, которые делают разные вещи, не означает, что ответственность не распределяется. AuthorEntityLoadService который я бы просто назвал AuthorEntityService управляет AuthorEntity экземпляры на сервисном уровне. Изображение, если у вас был один класс с одним методом для каждого из создания, обновления, извлечения, удаления AuthorEntity, Это не имеет большого смысла.

И на

Любые предложения о том, как решить, какова ответственность с точки зрения класса?

Как дальнейшее чтение, попробуйте http://java.dzone.com/articles/defining-class-responsibility

Answer 2

Как правило, в этом типе n-уровневой архитектуры ваш уровень обслуживания предназначен для предоставления API транзакционных (или зависящих от ресурсов) операций. Реализация каждой службы может использовать любые зависящие от ресурса зависимости (например, DAO для конкретного источника данных), в которых она нуждается, но это позволяет потребителю службы оставаться независимым от этих конкретных зависимостей или ресурсов.

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