我有一个带有多个服务类的服务程序集。每个类将一组相关的服务方法分组。这些服务使用IoC和构造函数注入器实例化。
如果我有两个服务类,有时可能需要在另一个服务类中调用方法,那么为避免循环引用,处理这些方法的最佳方法是什么?
例如,假设来自两个不同服务类的两种服务方法(不一定是最实际的示例,但是为了简单起见):
public class UserService
{
public void RegisterUser(User user)
{
// Do a bunch of stuff needed to register a user
// Now call out to permission service to set up basic permissions
_permissionService.SetUpBasicPermissions(user);
}
}
public class PermissionService
{
public void GrantPermission(User user, int PermissionId)
{
// Add user permission to database
// Now call out to user service to do some other stuff on the user
_userService.TakeActionsOnUserAccount(user);
}
}
这是我可以看到的选项:
考虑到功能需要在两者之间共享,这是服务类应合并为一个类的标志。但是,如果真是这样,我是否最终会获得一个庞大的服务等级?是什么决定了如何拆分它们?
不要将两个类都组合在一起,而是将共享逻辑的方法移动到自己的服务类中(将用户和权限特定的逻辑留在各自的类中)。如果真是这样,我可能最终会获得其中一些共享服务,我认为这不是一件好事。
从一项服务到另一项服务所需的任何动作都应移至调用代码。这对我来说似乎很麻烦,因为我将删除潜在的依赖逻辑,并将其作为另一层关注点。换句话说,无论我在哪里调用_userService.RegisterUser(),现在每次调用后都必须立即调用_permissionService.SetUpBasicPermissions()。
允许一项服务呼叫另一项服务,但不能两者都呼叫。如果是这样,我该选择哪一个?我如何处理无法调用另一个的逻辑?
使用委托将依赖的服务方法注入到调用的服务方法中。 Bleh,这听起来很丑。
这些是我能想到的,但是我敢肯定,有些事情我会被忽略。
有什么想法吗?
提前致谢。
最佳答案
如果要使两个服务相互引用,则需要使用属性注入(或方法)而不是构造函数,以便可以在将它们传递给另一个类之前完全创建它们。
至于在某些情况下让一个服务调用另一个服务的设计,只要操作的逻辑流程有意义就可以。尽管可能的是将其最小化是一个更好的设计,因为增加的依赖关系会增加耦合,并且在单元测试中必须更紧密地映射行为。
关于design-patterns - 避免使用服务和DI进行循环引用,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/5672308/