Linq-to-sql to use or not to use – my conclusion.

A while back I posted about Linq-to-sql (L2S) and wondering if I should/could use it in a layered fashion and at the time I fully intended to try and come up with a coded solution to show how it could be done.

After much searching I found this article on Code Project showing how to decouple L2S and use unity to build the objects and I thought that I’d use that as a sort of template to see if I could reproduce the functionality myself.

However, after a brief experiment, I gave up on attempting to recreate the code myself, and the reason - its just too much trouble to do so.

As I was trying to create the code I re-examined why I was doing this in the first place and whilst I was looking to be able to use L2S in a layered fashion, I also wanted to do TDD and not need to have to create my own framework to do so.

It was after this bit of introspection I stopped trying to create the code necessary to do this.  The code project article demonstrated how much work would be required to decouple L2S in such a way as to enable me to do what I wanted and although you should be able to wrap all the additional functionality in an assembly you’d need to always use the extra code.

You may think ‘well if its in an external assembly its no bad thing’, but why do this when there are other ORM’s out there that will allow you to easily mock the data context, use POCO classes, TDD, etc?

I was also pointed towards PLINQO by Eric which allows you to provide additional business logic in the partial class for each entity and through its code generation it can do it very quickly, but this doesn’t allow you to mock the DataContext and break the layers apart.  It was because of this that I decided to not pursue PLINQO as a solution to my L2S conundrum.

So after all this what conclusion have I come to? I doubt I’ll be using L2S any time soon for anything other than trivial or prototype applications.

Of course you may have other thoughts and I’d love to hear them.