我有一个带有多个服务类的服务程序集。每个类将一组相关的服务方法分组。这些服务使用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/