服务是否应该引用另一个服务,或者呼叫者是否应该承担额外的责任?

时间:2009-10-20 23:03:09

标签: asp.net-mvc abstraction coupling

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

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

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

处理这种情况的建议或首选方法是什么?感谢

3 个答案:

答案 0 :(得分:0)

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

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

答案 1 :(得分:0)

我会使用{I} RegistrationService,它取决于IAuthenticationService和IProfile服务。

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

答案 2 :(得分:0)

如果控制器的任务是注册用户和创建配置文件,那么问题是什么?控制器可以调用多个服务。控制器用于一个目的,它不一定非常精细。

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