用非静态类包装静态类
我正在看一个项目，我发现一些很好奇的东西。
有一个静态类有一组方法，其中每个方法调用远程服务器。
该模板看起来像这样：
public static class DAI
public static ResponseObject ExecStatement(string db, string sql)
{
{ ... }
}
public static DataSetResponseObject GetDataSet(string db, string sql)
{
{ ... }
}
public static DataTableResponseObject GetDataTable(string db, string sql)
{
{ ... }
}
}
但是没有在项目的任何地方打电话给这个班。 相反，它会调用一个非静态的类容器。
public class ExecSP : IExecSP
{
string _db;
public ExecSP(string db)
{
_db = db;
}
public ResponseObject OutputAsResponseObject(string sql)
{
return DAI.ExecStatement(_db, sql);
}
public ResponseObject OutputAsDataSet(string sql)
{
return DAI.GetDataSet(_db, sql);
}
public ResponseObject OutputAsDataTable(string sql)
{
return DAI.GetDataTable(_db, sql);
}
}
现在，我认为唯一的两件事情是优点，即包装在非静态容器中时命名更清晰，并且传递的参数较少。
但我想知道，如果这是一个好主意，通过设计包装静态类与非静态？ 如果有其他原因，有哪些？ 因为我认为创建一个静态并打电话它会没事的。 但是这个项目使得它将所有静态类包装起来成为一个有意义的点。 我不知道为什么。
我过去做过类似事情的最常见原因是，如果静态方法是由第三方库提供的（即我没有编写它），但我不想编写直接使用依赖于该库。 在这种情况下，我会写我自己的类，并让它直接依赖。
假设我使用了一个接口（或者类似于你的例子），那么如果我决定使用另一个库的道路，我可以编写另一个实现相同接口的类，并在运行时交换具体类使用类似于依赖注入的东西）。
在我看来，他们正在试图使对象可注入，以便使代码更容易测试并稍后修改。
检查这篇文章：为什么使用依赖注入？
就我个人而言，我绝对不会这样做，我会做的是使用像Ninject或Unity这样的.NET依赖注入框架，以便在创建对象时将必要的引用注入到对象中。 这样做有许多优点...对于初学者来说，您可以创建单例对象，而无需实际使用静态成员，并且您可以更好地控制其生命周期。 如果你想做单元测试（你应该），那么用一个模拟对象代替你的单例是很简单的，如果你稍后决定，也许单身并不是最好的设计选择，那么注入一个对象被定义为其他的东西，比如主要的父视图模型等等。你正在看的项目可能使用这个中间类来启用我正在谈论的一些事情，但它永远不会像做适当的依赖注入。
链接地址: http://www.djcxy.com/p/82245.html