A question on Dependency Injection

Posts   
 
    
Jez
User
Posts: 198
Joined: 01-May-2006
# Posted on: 21-Aug-2007 17:23:17   

First let me say congrats on the new release smile

Today I was playing with the new DI mechanism and I was wondering why you decided to opt for using an attribute (DependencyInjectionInfo) for setting up the dependencies rather than a config file. At the start of the v2.5 beta I seem to remember something about .diconfig files being mentioned and I am curious why this didn't make it in to the final release.

On an unrelated note, I'd be interested in knowing how you plan on implementing LINQ support for vNext. From what I've seen so far, IQueryable looks rather messy.

Jez

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 22-Aug-2007 10:57:51   

Jez wrote:

First let me say congrats on the new release smile

Thanks! simple_smile

Today I was playing with the new DI mechanism and I was wondering why you decided to opt for using an attribute (DependencyInjectionInfo) for setting up the dependencies rather than a config file. At the start of the v2.5 beta I seem to remember something about .diconfig files being mentioned and I am curious why this didn't make it in to the final release.

The main problem with these separate config files is that they're separate from the code. So it is a second level of configuration which is actually not really useful in many situations. The only situation in which it is useful is if you have for example such a generic authorizer class however it's annotated with a very specific attribute for just a single entity so you can't re-use it 1:1 with another project which has a different entity: you have to alter the attribute.

Also discovery would be a bit of a problem, and if someone wanted such a fine-grained DI functionality, they are probably better off with a full DI solution like structuremap or spring.net. So we cut it so it's a bit simpler to setup, and the code was a lot simpler to write. simple_smile

On an unrelated note, I'd be interested in knowing how you plan on implementing LINQ support for vNext. From what I've seen so far, IQueryable looks rather messy. Jez

At first it does, but it's rather straight forward actually. The 'mess' comes from the fact that there is a 'context change' (for lack of a better word) between 2 languages where information from one scope is present in the other one. So the C# / VB.NET symbols are present and accessable in the scope of the Linq language, and the result of the linq language is present again in the C#/VB.NET language scope. This is always pretty complex, but not undoable.

What IQueryable<T> simply does is offering you a tree with elements. This tree represents the query and the source of the data should handle it to produce the data. The most straightforward approach is simply traversing the tree and with every node simply call a handler which does something, like emit a piece of SQL or create a predicate.

This can lead to issues if the order of the statements in the linq query is somewhat different, or you run into an unexpected or unwanted (at that point!) element in the tree. You therefore are forced to examine the tree in full, and replace elements in the tree with other elements which you DO understand in full. After that process you simply traverse the tree from top to bottom and as you run into solely elements you know, it works.

The holy grail is in the tree restructuring. That's a tough nut to crack. Matt Warren has put on his weblog a couple of articles how to build a provider and the code was pretty odd / complex to me, so that will be a bit of a challenge, but I have an advantage: all the hard stuff is already written, namely the LLBLGen Pro runtime lib simple_smile All I have to do is emit predicates, factories, relations and that's it (hmm, that sounded easier than it really is, but you get the idea wink )

Frans Bouma | Lead developer LLBLGen Pro
Jez
User
Posts: 198
Joined: 01-May-2006
# Posted on: 22-Aug-2007 12:13:32   

Thanks for the reply.

I haven't really done much with DI, but I always thought one of the main benefits was being able to easily swap out the injected objects with mock implementations. Using a config file this is quite easy to do (you'd have a 'live' config file and a 'mock' config file) but I'm not sure how you could do this with an attribute-based approach. Recently I've been playing with the Windsor Container but I'll have a look at Spring.NET too.

Matt Warren has put on his weblog a couple of articles how to build a provider and the code was pretty odd / complex to me

I've also been looking at Matt's examples as well as some of the "Linq to NHIbernate" code that Ayende posted. It certainly looks challenging wink

All I have to do is emit predicates, factories, relations and that's it (hmm, that sounded easier than it really is, but you get the idea)

So from this I'm assuming "Linq to LLBLGen" will be a wrapper around the existing predicate/relation (etc) objects? Will both approaches be fully supported going forward or do you think that you may eventually phase out the current approach in favour of a Linq-only implementation?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 22-Aug-2007 14:02:09   

Jez wrote:

Thanks for the reply.

I haven't really done much with DI, but I always thought one of the main benefits was being able to easily swap out the injected objects with mock implementations. Using a config file this is quite easy to do (you'd have a 'live' config file and a 'mock' config file) but I'm not sure how you could do this with an attribute-based approach. Recently I've been playing with the Windsor Container but I'll have a look at Spring.NET too.

DI is not only for TDD, in fact we added it for ease of use with the authorizers, validators etc. so you don't have to define CreateValidator, CreateAuthorizer etc. methods in the entities.

Sure, using DI for TDD is a way to use it, but it's not the intention of our implementation. You could btw use it for mocking, though you need to add attributes to your mocks as well and then via the .config file of your application define which assembly the injectable objects are read from.

Matt Warren has put on his weblog a couple of articles how to build a provider and the code was pretty odd / complex to me

I've also been looking at Matt's examples as well as some of the "Linq to NHIbernate" code that Ayende posted. It certainly looks challenging wink

Linq to NHibernate seems kind of dead (not maintained) and it also doesn't optimize the tree so it will likely run into problems with some linq queries.

All I have to do is emit predicates, factories, relations and that's it (hmm, that sounded easier than it really is, but you get the idea)

So from this I'm assuming "Linq to LLBLGen" will be a wrapper around the existing predicate/relation (etc) objects? Will both approaches be fully supported going forward or do you think that you may eventually phase out the current approach in favour of a Linq-only implementation?

The predicate system will always be no. 1. Our Linq implementation is another way to formulate the predicate objects etc., but it won't replace it, as there are situations were linq isn't that useful or limited.

Frans Bouma | Lead developer LLBLGen Pro