在业务逻辑层中使用静态类答案

【问题标题】：Using static classes in Business Logic Layer在业务逻辑层中使用静态类
【发布时间】：2011-11-17 16:14:44
【问题描述】：

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

考虑一个简单的 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();
}

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

那么您是否建议我应该将我的真正应该是静态的 Manager 类更改为静态类？还是可以按原样使用它们？

【问题讨论】：

什么是存储库？我在工作中习惯于使所有业务对象无状态，因为我们的系统是多用户的，如果我们使其无状态，我们就可以创建一个所有用户可以共享的业务对象实例，而不会弄乱彼此的数据。

标签： design-patterns static business-logic n-tier-architecture

【解决方案1】：

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

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

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

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

BusinessRepository.Users.DoSomething();

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

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

imho 静态类只不过是函数的容器（而不是真实的对象）。不同的是，非静态类可以通过构造函数进行派生和获取依赖。

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

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

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

【讨论】：

使用 IoC 控制经理的创作是我最可能选择的路径。