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

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

那么您是否建议我应该更改我的Manager类，这些类确实是静态类的静态类？或者可以正常使用它们吗？

Answer 1

imho静态类只不过是函数的容器（而不是真正的对象）。不同之处在于可以派生非静态类并通过构造函数获取它们的依赖关系。

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

你可能没有打算让他们成为今天的实例，但明天呢？如果将它们更改为静态，则必须重构所有依赖代码以将其静态化。

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

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

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

很多人不同意这些“全局变量”，因为他们会称之为“全局变量”，但这是你的判断号召。您似乎已经决定对此感到高兴，因为您已经在讨论静态类了。

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

3 个答案: