A generic repository

Way back in January I said that I was going to post on a generic repository, due to various other diversions during the year I never managed to get around to completing this work but on the last day of the year it is finally all done and to tick off one of my goals here is the post about it.

What’s it all about?

When talking about both Linq to Sql (L2S) and Entity framework (EF) you will frequently hear developers saying that they will be using a repository to encapsulate the ORM interactions, what this means in practice is hiding the actual ORM functions and providing a abstract class or interface you can mock to make it easier to test your applications.

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.

Linq-to-sql to use or not to use

Following on from my previous post I mentioned the problems encountered trying to use an ORM for the first time, specifically linq-to-sql.

In the recent project where my team used Linq-to-sql (L2S) we were using Asp.Net Dynamic Data and we ended up with lots of data access in the code behind.  I plan to cover our experience of using Dynamic Data in an application in a future post but let me say now its not what I expected – and not in a good way.

So the team moved onto another project and we wanted to be able to put a proper layered design in place with a presentation, business logic and data access layers and immediately ran into a problem in that if we wanted to create an app that conformed to good design principles e.g. Dependency Inversion Principle, then we were going to run into a few issues.

Now I know that I’m way behind the curve on the use of L2S as most of the blog posts and articles I’ve been reading are from back in 2007, but I have been having a bit of difficulty finding information about using L2S in a layered and tiered system which worries me since it may be a case of “it doesn’t do it but you can make it do it” which is a code smell to me.

So far I’ve found a few articles and the one thing that strikes me is the amount of additional work that is required to make L2S work in a layered way, I know that it doesn’t support POCO but at the same time simply using it as an ORM seems to be more difficult than I would have hoped.

The following articles are a good summary of the information I’ve found and I’m still looking into this to see what I can find.

Using the IRepository pattern with Linq-to-SQL
Linq to Sql – How-to Separate the entities and the DataContext.
LINQ to SQL Queries out of a Business Layer

ORM – peril of the first time users

My team has recently got to grips with Linq-to-Sql and in the whole its all gone smoothly but there was one issue that the team had to overcome.

Our team is normally very good about data access, up to this point we have used stored procedures for all data access but only when needed. However, with Linq-to-sql that started to go out the window with calls to the database being made all over the code.

One of the worst examples that killed performance was calling the database to retrieve data for each record that is being displayed in a grid, now this is something that normally the team would have never done.

We had been using linq-to-objects for a while and so were used to working with objects in memory with no performance problems.  Now linq-to-sql syntax looks like linq-to-objects and you can believe you are simply calling a method on an object rather than the database and it is this reason that I believe we had the a problem, simply we forgot we were calling across the network to the database.

So the cautionary tale is this – when using an ORM don’t forget all your previous database knowledge and if you are not containing the data access to its own layer then be mindful of where you are using it.