Разделяет ли классы Service Layer принцип SRP?

Question

Ну, это пришло мне в голову, когда я смотрел видео SOLID. Принцип Single Responsabily говорит, что «класс должен иметь только одну ответственность».

Это хорошо. Но в то же время я работаю над проектом ASP.NET MVC 5, созданным в модели N-Layer. У нас есть слой пользовательского интерфейса, слой репозитория, уровень домена и уровень обслуживания. На уровне обслуживания у нас есть в основном один класс за Домен класс (UserService, CompanyService и т. Д.). Класс UserService обладает одной ответственностью, которая должна заботиться о действиях User, но, с другой стороны, у нее есть много разных ответов, таких как аутентификация и взаимодействие с этим отношением Пользователь/Компания. Это нарушение принципа SRP?

Answer 1

Конечно. Фактически, количество строк кода этого класса должно быть очень большим, это явная индикация запаха кода.

Когда вы говорите об одной ответственности, вы должны думать о причинах изменения. Почему мой код может измениться? В примере, который вы указали, я могу думать о нескольких причинах: я решил изменить систему auth, способ работы моей базы данных, как я делаю валидацию ... Все они являются подсказками, чтобы сделать разные классы с результатами AuthService, UserValidator, UsersRepository ...

Когда вы описали нам, что ваш класс делает, вы использовали слово «и»: «как проверка подлинности и иметь дело с этим отношения пользователя/о компании». Это еще один симптом вашего класса, который делает слишком много. Если вы не можете описать класс, не используя «и», вы, вероятно, нарушите принцип

Хотя вы твердо уверены, что эти возможности изменения не произойдут, потому что система будет всегда хорошо, это хорошо разделить код потому что код будет лучше организован и проверен.

Answer 2

Он нарушает SRP только в том случае, если вы поставили всю реализацию с множественной ответственностью внутри. В SRP класс может иметь одну и только одну ответственность. Управление работой пользователя является одной из обязанностей, но может быть нарушено и до суб-ответственности, например authorization, company relation и т. Д.

Каждая субподрядка может быть реализована как каждый отдельный класс. Затем ваш UserService будет использовать эти подклассы вместе как aggregate services. например:

public class UserService{ 
    public UserAuthorizationService UserAuthorizationService = new UserAuthorizationService(); 
    public UserCompanyRelationService UserCompanyRelationService = new 
UserCompanyRelationService(); 

    public bool IsAuthorized(){ 
     // use UserAuthorizationService 
    } 
    public // whatever you do with UserCompanyRelationService 
}