Click here to Skip to main content
14,740,854 members
Articles » General Reading » Uncategorised Technical Blogs » General
Technical Blog
Posted 29 Dec 2009

Tagged as



Introducing Hiro.Functors, and Making Hiro a Dynamic Container

Rate me:
Please Sign up or sign in to vote.
0.00/5 (No votes)
29 Dec 2009LGPL3
Introducing Hiro.Functors and making Hiro a dynamic container

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();

var container = map.CreateContainer();

// ..Use the container code here

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:

// For the sake of simplicity, let's assume that Foo has already been instantiated..
var existingFooInstance = new Foo();

// Define the factory functor
Func<IMicroContainer, object> makeFoo =>existingFooInstance;

var map = new DependencyMap();
map.AddService(typeof(IFoo), makeFoo);
var container = map.CreateContainer();

// Get the foo service; The makeFoo functor will be called here
var actualFoo = container.GetInstance<ifoo>();

// This will evaluate to true
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.)


This article, along with any associated source code and files, is licensed under The GNU Lesser General Public License (LGPLv3)


About the Author

Philip Laureano
Software Developer (Senior) Readify
Australia Australia
No Biography provided

Comments and Discussions

-- There are no messages in this forum --