views:

257

answers:

1

I got some static classes with extension methods which add 'business logic' to entities using the repository pattern.

Now sometimes i need to create a new IRepository in these extension functions.

I'm currently working around it by accessing my Ninject kernel through the object I'm extending, but it's really ugly:

public static IEnumerable<ISomething> GetSomethings(this IEntity entity)
{
    using (var dataContext = entity.kernel.Get<IDataContext>())
        return dataContext.Repository<ISomething>().ToList();
}

I could also make a static constructor, accessing the Ninject kernel somehow from a factory, is there already infrastructure for that in Ninject 2?

Does anybody know a better solution? Does anybody have some comments on this way to implement business logic.

+1  A: 

On the issue of extension methods and how they get stuff. You have two approaches:

  1. Service Location - have a global Kernel and drop down to Service Location (which is different from Dependency Injection). The problem here though is that your Entity (or its extensions) should not be assuming its context and instead demanding it

  2. As you are an extension method have the thing you're extending pass you what you need

As you've more or less guessed, this (Having a global Kernel that becomes the dumping ground) is something that Ninject tries to dissuade you from. In general, the extension for whatever the you're using (e.g., MVC or WCF) will provide something if its appropriate. For example, the WCF extension has http://github.com/ninject/ninject.extensions.wcf/blob/master/source/Ninject.Extensions.Wcf/NinjectServiceHost.cs

The larger issue here is that dependencies like this should probably not propagate down to the Entity level - it should stay at the Service level and be propagated from there (using DDD vocabulary).

You may find this answer by me interesting as it covers this ground a bit (more from a Ninject techniques that an architectural concepts perspective)

Ruben Bartelink
Thanks for your answer. I'm not very fond of the service location either, in my opinion it's even uglier the what i'm doing now.I'll go with the larger issue here, that this is not the right place to add business logic.I was hoping there was some magic way to inject a static constructor. So i could keep my design and not making it too ugly.I'll keep the question open for another few hours and if no AOP genius comes along i will accept your answer!
JJoos
You'll find no geniuses here - just people who trawl out answers on the forums - they're all on the Ninjecxt mailing list :D Bottom lin is that for static methods [like extension methods], that there is no context or opportunity to intercept in any easy manner. It is possible to flow context down into the Entity at the point of `new`ing in various ways (NHibernate and L2S each have their own ways). Problem is you dont want entities to be taking matters into their own hands and chasing around into other repositories willy nilly. And efficiency will also suffer - unless you go a Hiro-like route.
Ruben Bartelink
The Evans DDD book (a serious must-read no matter what you do, even if it hurts your head a little to absorb it) and/or http://thinkddd.com/ will really help you think through your overall design here. If you're really looking for heavy duty AOP stuff, you'll find that in Pthe direction of PostSharp.
Ruben Bartelink