Wrapping up static class with non
I was looking at a project and I found something very curious.
There is a static class that has a set of methods, where each method makes a call to a remote server.
The template looks kind of like this:
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)
{
{ ... }
}
}
But no where in the project makes a call to this class. Instead, it makes a call to an non-static class container.
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);
}
}
Now, the only two things I see as an advantage is that the nomenclature is more clear when wrapped up in a non-static container, and that there are less parameters to pass around.
But I'm wondering if this is a good idea by design to wrap up static class with non-static? What are some of the other reasons if there are any? Because I assumed that creating a static and making calls to it would be okay. But this project has made it a deliberate point to wrap up all static class; and I'm not sure why.
The most common reason I've done something like this in the past is if the static methods are provided by a third-party library (ie I didn't write it), but I don't want to write code that takes a direct dependency on that library. In that case, I'll write my own class and have it take the direct dependency instead.
Assuming I use an interface (or something similar like in your example), then if I decide down the road that I want to use a different library, I can write another class that implements the same interface and swap out the concrete class at runtime (using something like Dependency Injection).
Looks to me like they are trying to make the object injectable in order to make your code easier to test and to modify later.
check this post: Why does one use dependency injection?
Personally I would never do this, what I would do instead is use a .NET dependency injection framework like Ninject or Unity in order to inject the necessary references into objects as they're being created. There are many advantages to doing this...for starters you can create your singleton objects without actually having to use static members and you have much more control over their life cycle. If you want to do unit testing (and you should) then it is trivial to replace your singleton with a mocked object, and if you decide later on that maybe a singleton isn't the best design choice then it's trivial to inject an object that is scoped to something else such as the main parent view model etc. The project you're looking at is probably using that intermediate class to enable some of the things I'm talking about, but it'll never be as flexible or clean as doing proper dependency injection.
链接地址: http://www.djcxy.com/p/82246.html下一篇: 用非静态类包装静态类