One of the more salient criticisms that I've often heard about Hiro is the fact that for the most part, the containers that Hiro creates are static
and cannot be modified once they have already been compiled and instantiated. There might even be cases where you might have to have a Hiro-compiled container return an existing service instance, and that service instance (in turn) might not be available when the container is first compiled. For example, let's assume that you have an existing service instance of class type Foo
that implements the IFoo
interface
:
public interface IFoo
{
}
public class Foo : IFoo
{
}
Let's also assume that Foo
is some sort of long running service that must be returned every time you ask for an IFoo
instance from a Hiro-compiled container. In previous revisions of Hiro, you probably could have registered the IFoo
service as a singleton using the following code:
var map = new DependencyMap();
map.AddSingletonService<ifoo>();
var container = map.CreateContainer();
The problem with the previous code above is that you can't use it if the Foo
instance has already created before the container instance has been compiled. Since the hypothetical Foo
service is a long-running service that already exists before each container is compiled, there doesn't seem to be any way to make a DependencyMap
return an existing object instance--that is, until now. This is where Hiro.Functors
comes to the rescue:
var existingFooInstance = new Foo();
Func<IMicroContainer, object> makeFoo =>existingFooInstance;
var map = new DependencyMap();
map.AddService(typeof(IFoo), makeFoo);
var container = map.CreateContainer();
var actualFoo = container.GetInstance<ifoo>();
Assert.AreSame(existingFooInstance, actualFoo);
As you can see from the code above, the Hiro.Functors
library extends Hiro
so that you can use C#'s native lambda syntax to add your own custom factory methods to any Hiro-compiled container. A single call to the additional DependencyMap.AddService(yourServiceType, yourFunctor)
is all you need to convert Hiro from a static container to a dynamic container without sacrificing speed for flexibility. It's just that simple.
I prefer to call Hiro the "blue collar" IOC container framework, and Hiro.Functors
is just another step in helping you (the end-user developer) get the job done with as little drama as possible in the fewest amount of steps possible. While there's definitely nothing revolutionary about this tiny release, I think there's plenty to be said about having an IOC container that gets in and does the job using the flattest learning curve possible, and that's exactly what Hiro offers.
While I can't promise my readers that I'll change the world with revolutionary tools, what I will promise them is that my tools will be the simplest tools that they can possibly use so that they'll be able to meet their deadlines on time and make it home early for holidays like today. Hiro is one such tool, and if you ever run into any problems with it, I'm only a patch and an email away. Happy holidays, everyone!
(Note: You can get Hiro.Functors
here.)