I just had an interesting conversation with the co-editor of this blog which went something along the lines of…
BigMart: I haven’t had chance to dig into LINQ properly but I don’t like it
Me: But delayed execution rocks (follow long rambling explanation)
BigMart: For our next project I won’t be using that MVC rubbish
Me: But it rocks!
OK I’m paraphrasing and neither of us actually talks like that. However it did get me thinking about my willingness to follow the pack (people like Rob Conery ;-)) when it comes to these kind of developments.
I’m not entirely sold on the approach Rob has taken with his MVC storefront app, but then it seems neither is he, however there’s a lot in there that I like.
I’m new to LINQ (specifically LINQ2SQL) and at first couldn’t see any reason to use it over Subsonic. However then I delved into the Storefront app a bit more and I can see why Rob’s drawn to it.
Take a simple address query…
Address is a simple class with several properties.
The key thing to note about this is that nothing gets executed until we actually try to do something with this function. Calling GetContacts() won’t execute any SQL until we try to do something with it (like retrieve a generic list for example).
Why is this important? Well it means that you can further refine your query before executing it.
Lets say the above method is in a class called SqlContactRepository and now we’re going to write some business logic to deal with addresses.
This code looks for a specific address (by Id in this case) and then returns it. Because of delayed execution nothing will touch our database until we call
So what have we achieved? Well we have a nice simple repository which maps our database to our model (address).
We then have a higher level Service which can retrieve the IQueryable object, query it some more and then eventually execute the sql and grab the result directly into our model.
If we need a list (rather than a single object) we can simply do the following…
Throw MVC into the equation and things get really interesting. Now we have a simple Contacts Service which returns a generic list of addresses. Its simple to write an MVC controller to retrieve the data and pass it to a view.
Approaching all of this with interfaces (IContactRepository, IContactsService) you can easily write unit tests from the repository right the way up to the controller. Everything is loosely coupled, you can swap your repository out at any time (as long as you continue to return IQueryable objects to the service).
That said there are frustrations with this approach (as Rob has also identified). My own personal concerns lie around…
- Responsibilities – deciding where to put the business logic (its easy for the Service and Repository responsibilities to become muddled)
- Mocking – I prefer to use a mock framework (e.g. Rhino Mocks) for unit testing and mocking IQueryable is tricky, you tend to end up having to use test repositories instead
So what’s the conclusion? Well firstly I really like ASP.NET MVC. Even in this simple example it’s clear that I don’t have to worry about the presentation logic whilst I’m developing the main business logic. Add to that the fact that I can easily unit test right up to the controller level and I’m sold on it.
LINQ clearly has some major plusses in terms of its delayed execution and mapping to custom objects. The SQL generated is generally fine and I’ve not run into any performance concerns (yet).
Overall only time will tell but so far I think MVC 1.0 (whenever it’s released) and LINQ will be a viable solid basis for a robust Web App.