Initially, I thought this to be a bit of a shame. I hadn't got round to making propper use of this facility although it always seemed pretty cool. Allowing your stored procedures to be published as a web service without having to do any coding seems very attractive, so why have Microsoft decided to get rid?
One possibility could be the emergence of .NET 3.5 and specifically Linq.
I come from a SQL development background and I've always thoroughly believed that all data manipulation should be carried out in the SQL Server, so I'm used to using stored procedures for just about all interactions between my applications and the data. However, in my most recent role I'm under huge time constraints and I'm being asked to produce a hugely complex system which can be handed over to an in-house junior developer after I'm done. It's because of this I wanted to reduce the number of skills needed to maintain the system.
Now I'm not saying that Linq is going to mean the new developer won't need to work with SQL Server but while he's still inexperienced with SQL, he doesn't have to write much. Instead he can work in C# which he's much more familiar with.
I have to admit that initially I was dubious with Linq. I don't believe that the translation of managed code to SQL is as efficient as writing a stored procedure would be, especially the first few times you use Linq. Having said this, I'm really very pleased with the results. The SQL being produced by Linq is not what I would have written manually, but unless it was to be executed over and over a few thousand times the difference isn't really noticable. It's worth noting that the system I'm building is a line of business application come time management come document management system - a user's path through any task rarely hits the database very hard. So maybe I shouldn't be surprised that the performance seems adequate.
Does this mean we seeing the technology of publishing SQL code to a web service without having to write the web service getting replaced with writing a web service which interacts with SQL Server without having to write any SQL code?
Some obvious benefits of this method over the usual interaction with stored procedures would be:
- It's in managed code - it isn't everyone who is as at home writing SQL as they are managed code.
- Exception handling - no half way house, exception handling with Linq to SQL is exactly the same as with anything else written in managed code.
- No need to write copious amounts of code passing SQL values to managed objects.
There are probably more, but these three tend to get banded around the most.
As I am so insistant on efficiency of code, I found the lack of solid examples of how to make more complex queries efficient quite frustrating. In fact, the life of the DataContext itself is a huge issue, especially when building a web application with the possibility of many concurrent users. This is why I've decided to write about my own experience in the hope it will help someone else in a similar situation.
I'll begin in my next entry: Linq to SQL for Web Applications.
