在c#中何时声明成员方法

本文关键字：声明 成员方法 何时 | 更新日期: 2023-09-27 18:04:40

这是我的情况:(这是一个ASP.net MVC 5的控制器)

public class Class1
{
    public Class1()
    {
    }
    public void MethodA()
    {
        UserBLL bll = new UseBLL();
        // some code that call method from bll
    }
    public void MethodB()
    {
        UserBLL bll = new UseBLL();
        // some code that call method from bll
    }
}

我使用了两次UseBLL。(可能还不止十次)。所以我认为我应该这样声明一个对象成员

public class Class1
{
    UserBLL bll;
    public Class1()
    {
        bll = new UseBLL();
    }
    public void MethodA()
    {
        // some code that call method from bll
    }
    public void MethodB()
    {
        // some code that call method from bll
    }
}
这是一个明智的决定吗?如果不是，为什么?

我是否应该将UserBLL bll;更改为UserBLL bll {set;get };(当我需要这样做时?)

谢谢你的帮助:)

在c#中何时声明成员方法

看情况。:)

你需要考虑的是:

  • 状态(UserBLL是否保持状态，您是否希望保持状态?)
  • 线程安全(多个线程可以同时访问它并导致损坏吗?)
  • 制作成本有多高?

然而，我的典型方法是应用依赖倒置原则。这意味着UserBLL将实现一个接口，当创建Class1的实例时，构造函数将提供实现IUserBLL的类并将其存储在private readonly字段中。

的例子:

public class Class1
{
    private readonly IUserBLL _userBll;
    public Class1(IUserBLL userBll)
    {
        // Null checks here...
        _userBll = userBll;
    }
    public void Method()
    {
        _userBll.DoSomething();
    }
}

您仍然需要考虑上面的前两点，但是现在您有了一个一致的方法，您不需要担心_userBll到底是什么，并且可以在不影响Class1的情况下更改它。

通常，这种将对象注入构造函数的场景是使用IoC容器(有时称为"DI容器"或"DI框架")实现的。

所以后续阅读:

  • 依赖倒置原则
    • 控制反转容器(例如:Ninject, Castle)。Windsor, StructureMap, Autofac).

是的，把bll放在类级别上似乎是个好主意。

由于您将其设置为private(隐式)，这也是一个好主意，因此只有一个字段是可以的，就像您所做的那样;你似乎不需要一个属性(get和set)。

我建议你把你的字段标记为readonly，因为你只想在实例构造函数中分配给它。

正如在您的问题的注释中所说，您还可以考虑让实例构造函数接受参数，如:

public class Class1
{
    readonly UserBLL bll;
    public Class1(UserBLL bll)
    {
        this.bll = bll;
    }
    // ...

或者:

public class Class1
{
    readonly UserBLL bll;
    public Class1(UserBLL bll)
    {
        this.bll = bll;
    }
    public Class1() : this(new UserBLL())
    {
    }
    // ...

如果您希望经常使用UserBLL，那么它可能有一些优点，主要是更容易访问。但是我会小心地公开setter，因为使用主类的客户端将能够更改它。你可以只使用getter:

来防止它
private UserBLL _Bll;
internal UserBLL Bll
{
    get
    {
        return _Bll;
    }
}

然而，如果外部使用UserBLL的方法只在有限的情况下发生(就像你已经提出的两个方法)，并且你需要使用类中的数据修改UserBLL的结果，那么通过类中的方法公开UserBLL是一个更实际的决定。

总结一下，你的决定应该取决于:

1) UserBLL的暴露程度
2) UserBLL与Class1之间的交互水平

这似乎不是一个技术问题，而是一个概念问题。一个类代表了你所知道的对象的定义，在这种情况下，你必须问自己几个问题:

    UserBLL类是属于class1类还是属于method类?当你从你的类创建一个对象时，你需要使用UserBLL吗?

Class1 c = new Class1();
c.UserBll.MethodA(...)
  • UserBLL是否只在方法中使用而不会被重用?
  • …

如果你将UserBLL声明为类的属性，UserBLL将属于这个类。考虑概念和使用，你就知道你必须如何设计你的类。

在你的例子中，如果你在所有方法中使用UserBLL类，我认为你可以将它添加为属性，如果你需要在类的方法之外使用它你可以将它放在public中使用get，否则是private，如果你需要通过类中的其他方法更改它你可以在属性中添加set。

相关文章：