IoC

Zero friction IoC: Auto registration is mandatory

Ayende Rahien — Tue, 13 May 2008 13:08:57 GMT

This is the entire Binsor config file for a real application:

import Castle.MonoRail.Framework
import Castle.MonoRail.WindsorExtension
import Rhino.Commons.Facilities from Rhino.Commons.ActiveRecord

facility MonoRailFacility
facility RhinoTransactionFacility
facility ActiveRecordUnitOfWorkFacility:
	assembly = "HibernatingRhinos"

for type in AllTypesBased of IController("HibernatingRhinos"):
	component type.Name, type
	
for type in AllTypes("HibernatingRhinos").WhereNamespaceEq("HibernatingRhinos.Services"):
	component type.GetServiceInterface(), type

And I am pretty confident that I am not going to have to do much in the future with those.

And yes, you can do it with the fluent registration API as well.

Binsor & Auto Registration - Making it even simpler

Ayende Rahien — Tue, 13 May 2008 05:21:51 GMT

Here is the syntax that I am getting at...

for type in AllTypesBased of IView("Rhino.Commons.Test"):
	component type
	
for type in AllTypesWithAttribute of ControllerAttribute("Rhino.Commons.Test"):
	component type
	
for type in AllTypes("Rhino.Commons.Test") \
	.WhereNamespaceEq("Rhino.Commons.Test.Binsor"):
	component type

for type in AllTypes("Rhino.Commons.NHibernate") \
	.Where({ t as System.Type | t.Name.Contains("NHRepository") }):
	component "nh.repos", type.GetSeriveInterface(), type

And this seems to cover just about any scenario that I can think of. Combine that with Binsor's extend facility, and we are more or less done.

Adaptive Domain Models with Rhino Commons

Ayende Rahien — Thu, 27 Mar 2008 09:16:19 GMT

Udi Dahan has been talking about this for a while now. As usual, he makes sense, but I am working in different enough context that it takes time to assimilate it.

At any rate, we have been talking about this for a few days, and I finally sat down and decided that I really need to look at it with code. The result of that experiment is that I like this approach, but am still not 100% sold.

The first idea is that we need to decouple the service layer from our domain implementation. But why? The domain layer is under the service layer, after all. Surely the service layer should be able to reference the domain. The reasoning here is that the domain model play several different roles in most applications. It is the preferred way to access our persistent information (but they should not be aware of persistence), it is the central place for business logic, it is the representation of our notions about the domain, and much more that I am probably leaving aside.

The problem here is there is a dissonance between the requirements we have here. Let us take a simple example of an Order entity.

As you can see, Order has several things that I can do. It can accept an new line, and it can calculate the total cost of the order.

But those are two distinct responsibilities that are based on the same entity. What is more, they have completely different persistence related requirements.

I talked about this issue here, over a year ago.

So, we need to split the responsibilities, so we can take care of each of them independently. But it doesn't make sense to split the Order entity, so instead we will introduce purpose driven interfaces. Now, when we want to talk about the domain, we can view certain aspect of the Order entity in isolation.

This leads us to the following design:

And now we can refer to the separate responsibilities independently. Doing this based on the type open up to the non invasive API approaches that I talked about before. You can read Udi's posts about it to learn more about the concepts. Right now I am more interested in discussing the implementation.

First, the unit of abstraction that we work in is the IRepository<T>, as always.

The major change with introducing the idea of a ConcreteType to the repository. Now it will try to use the ConcreteType instead of the give typeof(T) that it was created with. This affects all queries done with the repository (of course, if you don't specify ConcreteType, nothing changes).

The repository got a single new method:

T Create();

This allows you to create new instances of the entity without knowing its concrete type. And that is basically it.

Well, not really :-)

I introduced two other concepts as well.

public interface IFetchingStrategy<T>
{
	ICriteria Apply(ICriteria criteria);
}

IFetchingStrategy can interfere in the way queries are constructed. As a simple example, you could build a strategy that force eager load of the OrderLines collection when the IOrderCostCalculator is being queried.

There is not complex configuration involved in setting up IFetchingStrategy. All you need to do is register your strategies in the container, and let the repository do the rest.

However, doesn't this mean that we now need to explicitly register repositories for all our entities (and for all their interfaces)?

Well, yes, but no. Technically we need to do that. But we have help, EntitiesToRepositories.Register, so we can just put the following line somewhere in the application startup and we are done.

EntitiesToRepositories.Register(
	IoC.Container, 
	UnitOfWork.CurrentSession.SessionFactory, 
	typeof (NHRepository<>),
	typeof (IOrderCostCalculator).Assembly);

And this is it, you can start working with this new paradigm with no extra steps.

As a side benefit, this really pave the way to complex multi tenant applications.

DI & IoC are not about testing!

Ayende Rahien — Tue, 25 Mar 2008 23:16:21 GMT

Dependency Injection & Inversion of Control Containers are not about testing!

I hear this a lot recently. Dave Laribee mentioned that in the Hanselminutes podcast, The creators of Guise seems to think that this is the main concern (01:30 in the video).

Oh, those techniques help, obviously. But it is not about unit testing.

For me, it is like saying that the main purpose interfaces is to enable easier testing.

DI & IoC are about decoupling, better flexibility, having a central place to go to and increasing the maintainability of out applications. Testing is important, but that is not the first and foremost reason.

Non Invasive API, take 2

Ayende Rahien — Mon, 24 Mar 2008 22:58:25 GMT

A few days ago I presented my typical way of handling container driven polymorphism.

// only use for selection
public interface IRegion<T> : IRegion {}

public void SetRegion(DependencyObject containerElement, string regionName)
{
	IRegion region = (IRegion) IoC.TryResolve(typeof(IRegion<>).MakeGenericType(containerElement.GetType()));

	if (region != null)
		_regions.Add(regionName, region);
}

I got an email with some good questions, and it is worth a second post to clarify. The questions:

The only thing I don’t like is that a lookup in the form of TryResolve(typeof(IRegion<>).MakeGenericType(containerElement.GetType())) would infer an explicit wrapper type for ever possible UI container type. On one hand it gives me the fine grain control I need to specify a different wrapper for an inherited UI container. But on the other hand, it means that ListBox, TreeView, ComboBox and TabControl would all need their own custom wrappers even though they all derive from ItemsControl and all handle adding and removing child entities in the same way.

But if containerElement == typeof(ListBox), won’t TryResolve(typeof(IRegion<>).MakeGenericType(containerElement.GetType())) fail to resolve? TryResolve expects an explicit match. It would need to find a registration for IRegion<ListBox>, not IRegion<ItemContainer> right? (Assuming Unity here.)

Even if that worked, what if I want all elements that inherit from ItemContainer to be handled by IRegion<ItemContainer> except TreeView? Say I need to handle TreeView differently for some reason. What’s a nice way to handle the 80% rule generically but still allow an override for special cases?

My response to that is very simple. Take the same approach, but bigger. Here is all we need to make this happen.

public void SetRegion(DependencyObject containerElement, string regionName)
{
	Type current = containerElement.GetType()
	while(current != typeof(DependencyObject))
	{
		IRegion region = (IRegion) IoC.TryResolve(typeof(IRegion<>).MakeGenericType(current));
	
		if (region != null)
		{
			_regions.Add(regionName, region);
			return;
		}
		
		current = current.BaseType;
	}
}

Now, we can register the following:

IRegion<TreeView>
IRegion<MyCustomRegion>
IRegion<ItemsControl>

And no matter what we will send to SetRegion, we can modify the behavior merely by changing the registration of IRegion<T> implementations. Note that this doesn't assumes any capacity on the container (except the basic resolve-generic-service one).

This is also a very natural model to follow, in nearly all cases (there is an issue here regarding whatever we should consider interfaces as well, but that is beside the point for this demo, and I would generally not do that anyway).

Non invasive API - Now with an IoC container

Ayende Rahien — Wed, 19 Mar 2008 21:37:41 GMT

I talked about ways to avoid invasive API design, and a lot of people asked about how to handle this with a container. First, I want to make it clear that the previous example assumed that you can't rely on a container, so it used Poor Man IoC to do that. Now that we can assume that there is a container, this is another matter entirely.

The API design now shifts to allow me to select the proper implementation from the container automatically. This generally ends up being either as a naming convention on top of a fixed interface, or as a generic interface with a given type as a parameter. The decision depends on what you are doing, basically, and the capabilities of your tools.

For myself, I strongly favor the generic interface approach, which would give us the following syntax:

public interface IMessageHandler<TMsg>
	where TMsg : IMessage
{
	void Handle(TMsg msg);
}

public class EndPoint
{
	public void HandleMsg(IMessage msg)
	{
		// this should be cached and turned into a delegate
		// not reflection call
		GetGenericHandleMsgMethod().MakeGenericMethod(msg.GetType())
			.Invoke(this, new object[]{msg});
	}

	public void HandleMsg<TMsg>(TMsg msg)
		where TMsg : IMessage
	{
		IoC.Resolve<IMessageHandler<TMsg>().Handle(msg);
	}

}

There is some ugliness in invoking the method with the generic parameter, but this allows you to handle a wide variety of cases very easily.

Let us take another example, this time it is from the Prism.Services.RegionManagerService:

public void SetRegion(DependencyObject containerElement, string regionName)
{
	IRegion region = null;

	if (containerElement is Panel)
	{
		region = new PanelRegion((Panel)containerElement);
	}
	else if (containerElement is ItemsControl)
	{
		region = new ItemsControlRegion((ItemsControl)containerElement);
	}

	if (region != null)
		_regions.Add(regionName, region);
}

I don't really like this code, let us see what happens when we introduce the idea of the container as a deeply rooted concept:

// only use for selection
public interface IRegion<T> : IRegion {}

public void SetRegion(DependencyObject containerElement, string regionName)
{
	IRegion region = (IRegion) IoC.TryResolve(typeof(IRegion<>).MakeGenericType(containerElement.GetType()));

	if (region != null)
		_regions.Add(regionName, region);
}

Now the code is much clearer, we can extend it from the outside, without modifying anything when we add a new region type.

Evaluating IoC containers

Ayende Rahien — Fri, 14 Mar 2008 10:11:48 GMT

Scott Hanselman is learning IoC, and he listed a lot of the IoC frameworks on the CLR. I was also pointed to this comparison IoC containers.

I don't like that comparison, and I am not sure that I can quite explain it. Most of the time, comparison of IoC container focus on simple dependency resolving scenarios and the related configuration.

From my point of view, it is like deciding to use C# or Java after reading a comparison of the syntax of an if statement.

Dependency resolution is the most basic feature that an IoC container can have.

Of the top of my head (and probably biased toward Windsor, since that is what I tend to use), I would say that you need to think about the following points, instead of focusing on the baseline scenario:

Error handling
Generic components
Decorators
Interception
Configuration vs. Convention (in other words, how much smarts does the container have?)
Extensibility scenarios

Interception as an extensibility mechanism

Ayende Rahien — Thu, 24 Jan 2008 08:31:41 GMT

I got a request to allow system-mode for Rhino Security, something like this:

using(Security.ActAsSystem())
{
	// in here the security behaves as if you have permission 
	// to do everything
	// queries are not enhanced, etc.
}

It is not something that I really want to allow, so I started to think how we can implement this, I came up with the following solution:

public class AuthorizationServiceWithActAsSystemSupport : IAuhorizationService
{
	IAuhorizationService inner;

	public AuthorizationServiceWithActAsSystemSupport(IAuhorizationService inner)
	{
		this.inner = innner;
	}

	private bool IsActAsSystem
	{
		get { return true.Equals(Local.Data["act.as.system"]); }
	}

	public bool IsAllowed(IUser user, string operationName)
	{
		if(IsActAsSystem)
			return true;
		return inner.IsAllowed(user, operationName);
	}

	public void AddPermissionsToQuery(IUser user, string operationName, ICriteria query)
	{
		if(IsActAsSystem)
			return;
		inner.AddPermissionsToQuery(user, operationName, query);
	}

	// .. the rest
}

Now, all we need to do is register it first:

component IAuthorizationService, AuthorizationServiceWithActAsSystemSupport

faciliy RhinoSecurityFacility

And that is it. This both answer the requirement and doesn't add the functionality that I don't like to the system.

Again, neat.

AOP: Be aware where your point cuts are

Ayende Rahien — Wed, 19 Dec 2007 19:00:31 GMT

So, this issue cause some head scratching today. We are using WIndsor's Automatic Transaction Management with NHibernate's flush-on-commit option, so if a transaction doesn't commit, nothing is written to the database.

Anyway, this is a story about refactoring, and what it showed us. We performed the following refactoring:

Some things that is important to understand, the LoginController is decorated with [Transactional], and there is a [Transaction] attribute on CreateUserLoggedInAuditRecord.

When it was on the controller, it just worked. When we moved it to its own class, it didn't work. To be rather more exact, it worked, it just never committed the transaction. That was weird. After some head scratching I found out that I forgot to put [Transactional] on the UsageRegistrationImpl. With a small smile of geeky triumph, I run the code again. It didn't save.

That was really worrying, and I had no idea what was going on. Since this is rarely popular, I repeatedly run the code, hoping that something would turn up and that no one would pull the old quote about insanity.

After a few repetitions, I suddenly saw the light.

It had to do where I placed the pointcut. A pointcut, in AOP terms, is where the AOP can interfere with the running code. Let us take a look at how it worked when we used the LoginController directly. Because we (well, the transaction facility) asked the container to create an interceptor for it, we got the following classes at runtime:

The login controller is the original class, the login controller proxy was generated at runtime, and any invocation of any of its methods would fire the transaction interceptor, so it would get a chance to create/rollback/commit a transaction if needed. Since those methods are virtual, this means that even if I am calling methods on the same class, they will be intercepted correctly.

Now, when I moved to the interface + implementing class, we have a different behavior. Now, we use the interface pointcuts in order to inject behavior, it looks like this:

Windsor will create a proxy interface implementation that would call the AOP interceptors and will forward to the UsageRegistrationImpl.

The problem was with the RegisterUserLoggedIn method. It was similar to this:

public virtual void RegisterUserLoggedIn(string username)
{
	// do other things
	CreateUserLoggedInAuditRecord(username);
}

[Transaction]
public virtual void CreateUserLoggedInAuditRecord(string username)
{
	//do database stuff
}

Given the story so far, you can obviously see the problem. When we call the CreateUserLoggedInAuditRecord() method, we call it from the UsageRegistrationImpl class, so we never pass through any of the pointcuts.

When we used the method from the controller directly, we made a virtual method call, which was intercepted, but since in this case, we were using the interface as our pointcut, this simply by passed the whole thing.

That was an interesting lesson, and one that I'll need to remember for the future.

DSL & IoC - Combining powerful concepts

Ayende Rahien — Thu, 13 Dec 2007 07:42:50 GMT

I was just writing this line of code:

DslExecuter<SchedulingDslEngine>.Create(“validateWebSiteIsUp”)

When it occurred to me that this looks a look like an IoC resolve call. Which got me thinking about combining both concepts together, which gave me the shakes.

The idea is that we can expose those dependencies like this:

customers as ICustomerRepository
fraudService as IFraudService
alerts as IAlertService

for customer in customers.FindAll(With.Orders):
	for order in customer.Orders:
		if fraudService.IsFraud(order):
			alerts.ForFaurdOn(order)
			if customer.Important:
				alerts.NotifyCustomerAboutFraud(customer)

Leaving aside the mountain slope code*, consider what is going on here. We are exposing dependencies by specifying the types that we need. We can then get them through the IoC and execute the code in hand.

This means that the DSL has full access to everything in the application, and is subject to the same rules and behavior as all the other components. From my point of view... sweeeeeet.

* First example that popped to mind, yes, I know it is a bad one.