在业务逻辑层使用静态类

Question

我知道我的问题的答案可能涉及选择特定的方法，但我尝试详细解释我想要找出的内容：

考虑一个简单的 3 层应用程序（DAL、BLL、PL）。
DAL 使用 EF 4.1 Code-First，并且对数据的访问包含在存储库中。

现在，在 BLL 中，我有 Manager 类。 （例如UserManager、ProductManager），它们都派生自BaseManager。我的 Manager 类中的几乎每个方法都将其相关实体作为参数并对其执行适当的操作。例如在 UserManager （伪代码）中：

public bool AddPermission(User user, PermissionItem permission)
{
    this.repository.Add(permission);
    this.save();
}  

问题是：我的管理器类不需要实例化。它们可以被定义为静态的。
但是，如果我将它们定义为静态，我应该在每个类中创建我的共享方法和成员（如存储库和其他几个成员）（我不想将存储库等成员定义为静态）。

那么您是否建议我应该将确实是静态的 Manager 类更改为静态类？或者按原样使用它们可以吗？

Answer 1

恕我直言，静态类只不过是函数的容器（而不是真正的对象）。不同的是，非静态类可以通过构造函数派生并获取其依赖项。

尝试为静态类编写适当的测试。

您可能不希望它们成为今天的实例，但是明天呢？如果将它们更改为静态，则必须重构所有依赖代码以取消它们的静态状态。

我宁愿开始使用控制反转容器来管理它们的创建和实例。

Answer 2

我认为没有理由让它们静态。据我所知，这只会使 API 和实现变得复杂。您的调用者将从哪里检索存储库？他们应该为每个电话查找它吗？那太浪费了。最好查找一次并将其存储在管理器中。这就是实例变量的用途。

Answer 3

我喜欢创建一个包含所有实例的静态“目录”（该对象的正确名称实际上是存储库）。例如：

public static Class BusinessRepository
{
    private static Users users = new Users();

    public static Users Users
    {
        get
        {
            return users;
        }
    }
}

BusinessRepository 类是静态的，但 Users 是其中包含的实例对象。然后可以这样访问：

BusinessRepository.Users.DoSomething();

通过这种方式，您可以通过静态访问来保留对象实例及其带来的所有好处。

很多人不同意这些“全局变量”，因为他们会这样称呼它们，但这是你要做出的判断。看来您已经做出了对此感到满意的决定，因为您已经在谈论静态类了。