服务层类是否违反SRP原则？

Question

那么，当我在观看SOLID视频时，我想到了这一点。 单一责任原则说“一个班级应该只有一个责任”。

这很好。但同时，我正在ASP.NET MVC 5项目中构建N层模型。我们有UI层，存储库层，域层和要公开的服务层。在服务层上，我们基本上每个域类（UserService，CompanyService等）有一个类。 UserService类有一个负责处理User操作的责任，但另一方面，它具有许多不同的责任，如身份验证和处理该用户/公司关系。这是否违反SRP原则？

Answer 1

当然。事实上，该类的代码行数必须非常大，这是代码异味的明确指示。

当你谈到单一责任时，你应该考虑改变原因。为什么我的代码可以改变？在你举的例子中，我可以想到几个原因：我决定改变auth系统，我的数据库的工作方式，我做验证的方式......所有这些都是使不同类的结果的线索AuthService， UserValidator，UsersRepository ......

当你描述我们的类做什么，你所使用的“和”字：“如身份验证和处理用户/公司的关系”。这是你班级的另一个症状是做得太多。如果你不能使用“and”来描述课程，你可能违反了原则

虽然你坚信这些改变的可能性不会发生，因为系统总是很好，但它很好地划分了代码因为你会使代码更好地组织和测试。

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 
}