design-patterns - 避免服务和 DI 的循环引用

Question

我有一个包含多个服务类的服务程序集。每个类将一组相关的服务方法分组。这些服务是使用 IoC 和构造函数注入(inject)器实例化的。

如果我有两个服务类，有时可能需要调用另一个中的方法，那么处理这些类以避免循环引用的最佳方法是什么？

例如，假设来自两个不同服务类的两个服务方法(不一定是最实际的示例，但为了简单起见):

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);
    }
}

以下是我可以看到的选项:

1. 考虑到需要在两者之间共享功能，这表明服务类应该合并为一个类。但是，如果是这种情况，我最终会得到一个巨大的服务等级吗？什么决定了它们应该如何拆分？

2. 不要合并这两个类，而是将共享逻辑的方法移动到它们自己的服务类中(将用户和权限特定逻辑留在它们各自的类中)。如果是这样的话，我最终可能会得到一些这样的共享服务，我认为这不是一件好事。

3. 从一项服务到另一项服务所需的任何操作都应移至调用代码。这对我来说似乎有问题，因为我将删除潜在的依赖逻辑，并使其成为另一层的关注点。换句话说，无论我在哪里调用 _userService.RegisterUser()，我现在都必须在每次调用后立即调用 _permissionService.SetUpBasicPermissions()。

4. 允许一个服务调用另一个，但不能同时调用两个。如果是这种情况，我应该选择哪一个？对于无法调用另一个的逻辑，我该怎么办？

5. 使用委托(delegate)将依赖的服务方法注入(inject)到被调用的服务方法中。呸，这听起来很难看。

这些是我能想到的，但我敢肯定还有一些我忽略了。

想法？

提前致谢。

Answer 1

1. SRP 原则声明每个对象都应该有单一的职责，因此合并类是不行的。
2. 这就是发明的继承方式，对公共(public)代码使用抽象类并专门化(不使用引用)
3. 依赖逻辑很糟糕，RegisterUser 应该只做注册，而不是授予权限。把依赖移到调用层就可以了。
4. 只有在必要时才这样做，在你完成抽象类之后应该会有点清楚。尽管尝试对象组合。
5. 它叫容器，看了之后你应该会更好地理解它:http://www.potstuck.com/2009/01/08/php-dependency-injection

关于循环引用，OOP原则只是说要避免抽象类和具体类之间的循环引用(好莱坞原则)，其实不然。可以像您一样使用它们。

但是，您使用的依赖注入(inject)非常好，因此您可以提取 SetUpBasicPermissions 并将其放在类之外。

objUser = new User();
objUserService.RegisterUser(objUser);
objPermissionService.SetUpBasicPermissions(objUser);