是否应该为服务提供对另一个服务的引用，或者调用者是否应该承担额外的责任？答案

【问题标题】：Should a service be given a reference to another, or should the caller gain extra responsibility?是否应该为服务提供对另一个服务的引用，或者调用者是否应该承担额外的责任？
【发布时间】：2009-10-20 23:03:08
【问题描述】：

我的项目中有两个类（使用 ASP.NET MVC）：AuthenticationService 和 ProfileService。当新用户在我的站点注册时，Authentication 控制器的 Register 操作调用 IAuthenticationService 中的 Register 方法，该方法根据接口所指的任何具体身份验证模块为用户创建身份验证记录（注入到控制器的构造函数中）。作为注册过程的一部分，会为用户创建配置文件记录，这是通过在注入的 IProfileService 上调用 CreateProfile(User) 创建的。

目前控制器正在调用这两个服务，但我喜欢我的控制器执行尽可能少的业务逻辑的想法。我想知道除了让身份验证服务知道配置文件服务之外是否还有其他选择，这反过来又需要 IAuthenticationService 的任何未来实现知道调用 CreateProfile？我不禁觉得上面写满了代码味道。

另一种可能性是让第三个服务 {I,}RegistrationService 负责逻辑。

处理这种情况的推荐或首选方法是什么？谢谢

【问题讨论】：

标签： asp.net-mvc abstraction coupling

【解决方案1】：

我喜欢第三种方法。我的应用程序中有类似的情况，控制器需要多个域级服务来执行任务，并且代码对于控制器来说有点冗长。特别是，我有一个允许上传照片的活动管理系统。除了存储库和 IAuthService，物理存储由 IFileSystem 处理（我们可以在本地和 S3 之间切换），由 IThumbnailer 处理图像，由 IBackgroundTask 处理扫描/清理。

我已经开始做的是在域服务之外创建应用程序服务来处理责任，这样容器现在只主要注入应用程序服务（在你的情况下是选项 3）

【讨论】：

我想这就是我要做的，将注册过程提取到一个单独的服务（{I}RegistrationService）中。它只是看起来更干净。谢谢。

【解决方案2】：

我会选择依赖于 IAuthenticationService 和 IProfile 服务的 {I}RegistrationService。

作为一项规则，我的目标是每个控制器都有一个服务依赖项

【讨论】：

【解决方案3】：

如果控制器的任务是注册用户和创建配置文件，那是怎么回事？一个控制器调用多个服务是可以的。控制器是有目的的，它不必非常精细。

为通用注册创建第三个控制器，它使用对身份验证和配置文件的接口引用可能是更好的途径。然后身份验证和配置文件不耦合。

【讨论】：