c# – 实用程序类:静态类vs成员变量vs本地变量

我正在创建一个实用程序类CommonDaoOperations,它包含几个通用方法:Create,Update,Delete.
这不是基类,因为一些DAO更复杂,不能使用这些通用方法,但许多DAO可以.

我现在正在思考这个utiliy类应该是什么样子:

>静态类,只有静态泛型方法
>使用泛型方法的常规类,每个DAO创建一次作为私有只读成员
>使用泛型方法的常规类,每个DAO方法创建一次(在每次调用中)

每个DAO /方法创建一个类的实例显然比调用静态方法花费更多,但我很确定这些成本在几乎所有应用程序中都是可以忽略的.

我赞成解决方案2或3,因为非静态类的好处(接口,可以被模拟,可以派生/增强,如果有必要,可以在将来通过构造函数收集参数(与10参数相比)静态类中的方法)).

所以我想真正的问题是:我应该将我的实用程序类创建为成员变量,还是根据DAO方法实例化它?

public void Create(User user) { 
   new CommonDaoOperations().Create(user);
}
public void Delete(User user) {
   var daoOps = new CommonDaoOperations();
   daoOps.CheckSomething(); // just an example of multiple calls to the class
   daoOps.Delete(user);
}

我很想知道其他开发者对这些方法的看法,或者是否还有其他/更好的方法来做到这一点.

编辑

刚刚意识到我应该更多地考虑方法#3 – 正如Vadim指出的那样,当在每个方法中实例化时,替换具体类会很麻烦,但我可以将其考虑在属性中:

private CommonDaoOperations DaoOps {
    get { return new CommonDaoOperations(); }
}
public void Create(User user) {
   DaoOps.Create(user);
}

我相信这比上面的片段更具有主要性,但是知道我在我的DAO中引入了一个’实用程序’类的属性,这可能是代码气味本身(如Ant P指出的那样).

摘要

这是一个艰难的决定 – 虽然我接受了Ant P的回答,但Vadim的答案也是合法的.使用哪种方法取决于实用程序类,所有3种方法都有其用途(除了更新的#3).至少这是我对提供的答案的看法.

>静态类确实有它们的用途,但也有许多缺点,如上面简要提到的.
>常规类,按方法实例化:创建utiliy类并在需要的地方使用.减少依赖性,保持您的类型纯净.
>常规类,实例化为成员:当许多/所有方法都需要实用程序类的实例时,创建成员变量可能更好.通过这种方式更改类型或实例化方式变得更加容易.

最佳答案
我会对性能影响进行更合格的评论;但是,以下是我对每个问题的看法:

1.静态课程

这个概念适用于简单的,“不全面”的实用方法,它们不需要真正的可扩展性,但是 – 正如您自己记录的那样 – 您的常见DAO操作将变得更加复杂.作为单个静态类,这不太可能是非常易于管理的,特别是当它用于多种不同类型的DAO时.

2.具体类,实例化每个DAO对象

这一切都很好,花花公子,但你真的需要实用程序类成为单个DAO的成员吗?如果你在DAO的生命周期中需要某种实体类中的某种一致性或状态持久性,我可以理解这一点,但似乎这些方法相当模糊(因为它的名称是“实用程序”类).

其中有3.具体类,每个方法实例化.这对我来说似乎是最自然的解决方案.这使您可以灵活地利用具体类的所有优点,如您在问题中所承认的那样,同时将对象的范围限制在需要的位置 – 单个方法调用.

您的班级是否应该演变成整个DAO所需的内容,例如:你突然需要维护对象的状态(或者你需要将它注入到DAO的构造函数中,或者沿着这些行注入其他东西),你总是可以改变实例化的位置(虽然在我看来,如果发生这种情况,你不再有实用程序类了,你需要重新考虑这个类如何适合你的架构).

转载注明原文:c# – 实用程序类:静态类vs成员变量vs本地变量 - 代码日志