October 2009 - Posts
No, I haven’t chosen one to use yet. But I kind of feel that instead of investing more time in home-made and fairly inefficient DI classes, I should rewire the code to use one of the available IoC frameworks. And here are some blog posts that can help to make a choice.
Comparing .NET DI (IoC) Frameworks (part1 and part2) by Andrey Shchekin. Very good comparison with source code uploaded to Google Code.
IoC libraries compared by Chirs Brandsma. Focuses on most common case - constructor injection. Source code is also available.
Having read these two posts, I’d probably go with either StructureMap or Autofac. But I would also like to have a closer look at MEF that was not covered in these blog posts (I guess because it’s not a pure IoC container). Here’s an excellent Ayende’s post explaining why.
A couple of good sources for those who need to decide:
Capability comparison made by Morgan Soley. Half year old but with a feature comparison table.
Recently updated comparison by Andrew Kazyrevich.
TypeMock Isolator is a clear winner if it fits in your budget. Otherwise Rhino Mocks or Moq seem to be the most mature frameworks. According to a recent Roy Osherove’s pole they are in the lead with Rhino Mocks having 47% and Moq on second place with 34%. If I had to choose a free mocking framework today, I’d probably go with Moq because of Rhino Mocks’ confusing “very large array of syntaxes”. Or wait for Rhino Mocks 4.0 that will be radically simplified and, like Isolator, will go for AAA abd single “fake” concept.
But for mocking without severe limitations there is no alternative to Isolator. Still in the lead.
I am kind of slow with adoption of communication channels. But motivation works sometimes. Perhaps Twitter Geek Quiz that TypeMock is arranging this Wednesday can help me retraining my Twitter skills.
There will be prizes (from WiFi-detecting T-shirt to XBox), and to join is just to tweet any message with the quiz's hash tag – #GeekQuiz. Rules are listed here.
Latest Jeremy Miller’s article in MSDN Magazine will be very helpful for C# developers who haven’t started yet exploring functional programming. What is good about this article is that it gives practical advices on how to inject some fairly small pieces of functional programming into existing C# code in order to make it better – for example by removing code duplicates.
What seems to be radical for many C# developers is how functional programming handles blocks of code with variables that are not resolved within those blocks – closures. A piece of code with variables defined somewhere else is traditionally viewed by programmers with background in procedural languages as an invalid construction that will cause a compiler error. But closures are fully supported now in C# (in form of anonymous delegates or lambda-expressions), and Jeremy’s article demonstrates advantages of using this technique to pass around code blocks as data.
I think however that the example with ConnectedSystemConsumer could be presented somewhat simpler, without focus on Interface Segregation Principle. Here’s how the original class looks before refactoring:
class ConnectedSystemConsumer
{
private readonly IConnectedResource _resource;
public ConnectedSystemConsumer(IConnectedResource resource)
{
_resource = resource;
}
public void ManipulateConnectedResource()
{
try
{
// First, you have to open a connection
_resource.Open();
// Now, manipulate the connected system
_resource.Update(buildUpdateMessage());
}
finally
{
_resource.Close();
}
}
// The rest of the class is skipped
}
The article then introduces two new interfaces and one class: IResourceInvocation, IResource and Resource, where IResourceInvocation contains the “interesting” part of IConnectedResource (methods FetchData and Update) and IResource defines and Resource implements a single method Invoke that takes care of all ceremony stuff. While this helps splitting the original ConnectedSystemConsumer class into smaller logical blocks, for developer doing his first experiments with functional programming it may leave false impression that adding additional classes are required (or at least expected) steps to take advantage of functional programming in C# code. But the same effect can be achieved without adding new interfaces or classes, just by extracting all ceremony code in a separate method:
class ConnectedSystemConsumer
{
private readonly IConnectedResource _resource;
public ConnectedSystemConsumer(IConnectedResource resource)
{
_resource = resource;
}
public void ManipulateConnectedResource()
{
InvokeResource(x =>
{
x.Update(buildUpdateMessage());
});
}
private void InvokeResource(Action<IConnectedResource> action)
{
try
{
// First, you have to open a connection
_resource.Open();
// Now, manipulate the connected system
action(_resource);
}
finally
{
_resource.Close();
}
}
// The rest of the class is skipped
}
As you can see, ManipulateConnectedResource no longer contains ceremonial code that opens and closes resource and handles exceptions. This code is now moved to InvokeResource method that takes as an argument a block or a closure defined in ManipulateConnectedResource or any other method that requires the same ceremony.
After reading Jeremy Miller’s article I browsed some of my old code and found several classes that can be simplified using the same approach. Perhaps at first they will not look simpler – functional programming style adoption requires some time. But they will become more compact, with less or without code repetition, and this alone is worth it.
I usually don’t. I know that if I choose wrong name for a class, project or service, I am going to spend time on hating them later. And if there are several people in the team who have strong feelings about proper naming, they are going to bring back wrong naming issues and use their precious time on it. So unless the project is shipped, and names it exposes become a contract that you can’t violate, it’s worth sorting out all uncertanties about naming convention.
There is however an argument that name corrections should not have high priority because it’s just a refactoring that don’t change a thing in functionality. But does it really cost so much to fix wrong name that you should postpone it (and potentially increase the cost of change)? I tried to measure one such change.
Yesterday I revised one of our services that provided validation of payment limits. Originally it was placed in PaymentEngine/Limits folder, and the WCF service it exposed was called just Limits. It was decided to relocate WCF services and revise their names to better reflect its business purposes, so I moved the project to a new place under Services/LimtsValidation. The change also affected several configuration and Wix deployment files.
Right after I was done with my changes, one of my colleague commented that “LimitsValidation” is not the best name. If we apply the same guidelines and styles we use for other projects, we should call it “LimitValidation”, with the word “limit” in singular form. After a short discussion I agreed but added that I won’t correct the name now, and maybe we should just live with “LimitsValidation”. Well, it’s not a big deal, is it?
But when I came back home, I realized that it will be difficult for me to cope with a wrong name that I admitted was wrong. And the best time to fix it would be now, when I still remember what I did and which files I changed.
So today I came to work earlier and corrected spelling of the service name and related files. This is what it cost me:
- Files changed: 22 (including changes in projects, folders, namespaces, configuration and deployment files)
- Time spent: 25 minutes (including execution of selected integration tests to validate availability of affected services after the change)
As you see, it did not take much time to correct a naming mistake, but it would take much more if the correction was postponed until it no longer remained an internal matter. Then it could even become too costly to afford.