Selecting a service implementation based on business rules

Question

In an application I am working on, we have actions that trigger when a new entity is added to the repository. One of the new actions is supposed to use a service (as in, service layer, not web service somewhere in the ether) to perform some business-rule manipulations as the object comes in.

This is all well and dandy, but the exact service should be used will vary based on the properties of the entity that we are manipulating (basically, based on which customer the entity is related to). I would like to keep the action loosely coupled to the flavor of service that it may need to call.

What I am thinking about doing is implementing a factory that will accept the entity and return the correct service. This seems a little kludgy, though. Is there a better way to set this up?

I had considered using an IoC container to determine the correct implementation at runtime, but a quick perusal of a couple (Ninject and Windsor) does not seem to indicate that they are well-suited to this sort of operation.

Answer 1

I think for this iteration, we will keep it simple and use a factory to select the proper interface (i.e. the solution I thought was "kludgy" in the original post). Thanks for all the feedback!

Answer 2

I would recommend that you take a close look at MEF (Managed Extensibility Framework). This provides a very agnostic loose coupling that closely (if not exactly) fits your requirements.

Answer 3

You approach this the wrong way. You should use events for this:

// your repository event
public class ItemCreated<T>
{
}

The handlers:

public class DoSomething : ISubscribeOn<ItemCreated<User>>
{
    public class DoSomething(ISomeService)
    {}
}

Notice that it isn't the service itself but a middle man that subscribes on the event. It makes things less decoupled.

All of this is built into my IoC container: http://www.codeproject.com/Articles/440665/Having-fun-with-Griffin-Container

Scroll down to domain events.