From all the great tools we have out there such as LLBLGen Pro, nHibernate and OpenAccess, why do I stick with a half baked moving target from Microsoft? Simply because it is in the box? Not really, it is because this is what most clients will be ASKING me to use.
There are a lot of things to like about Linq to Sql, and yet there are a lot to dislike as well.
My #1 Problem with L2S is the way the DataContext works, it is in no way designed for use in a mostly stateless or disconnected scenario. With a little effort you can work around this with some generous use of attach and being careful how you load and save objects.
My #1 Problem with L2E is the way the object model works. I hate not having access to defined columns in my DB when I really do want them and there is no valid option in the designer to support them.
As an example for this, I have a Login table that deals with all my User Security. Every table has a CreatedBy and UpdatedBy column... They all have a foreign key mapping back to Login to make sure no one enters an invalid login in these fields...
This is a pretty common scenario and generally is no big deal. Except with the model proposed by L2E I will have hundreds of associations back to the Login Table (none of which get named properly even when all the FK_xxx names are set. I have to manually wade through all the tables and change the names on BOTH sides to something that makes sense.
This is AWEFUL! I would never, never use an association such as "give me all addresses updated by John". To make these matters worse, I can't even get the Address's CreatedById unless I load the entire Login object and reference it like this: Address.CreatedByLogin.LoginId which sucks when you are programming and creating queries.
Are there ways around this? sure, but they are all so complex and tedious that using L2E is simply too complex for 80% of my work. In the 20% case where I really do need the extra features complex mapping, I would be using some other tool such as LLBLGen Pro or OpenAccess because it is far easier to work with.
80% of our work is dealing with read-mostly scenarios and rich web presentations of the data.
What handles this best? Linq to Sql, why? Because it is easy to use and with Damien Guard's T4 Templates I can pound out a new DBML really fast.
Will Linq to Sql really die? Eventually, but not in the next couple years. here is a quote from Damien about it:
Where next
The decision has been made that Entity Framework is the recommended solution for LINQ to relational scenarios but we are committed to looking after our users and are approaching this in two ways.
Firstly we are going to make sure LINQ to SQL continues to operate as it should. This doesn’t just mean making sure what we had works in .NET 4.0 but also fixing a number of issues that have arisen as people pick it up for more advanced projects and put it into production environments.
Secondly we will evolve LINQ to Entities to encompass the features and ease of use that people have come to expect from LINQ to SQL. In .NET 4.0 this already includes additional LINQ operators and better persistence-ignorance.
This isn’t to say LINQ to SQL won’t ever get new features. The communities around LINQ to SQL are a continuous source of ideas and we need to consider how they fit the minimalistic lightweight approach LINQ to SQL is already valued for. Where these suggestions fit with this strategy we will be working hard to get them into the product. Some enhancements like the T4 templates can be released independently but runtime elements need to stick to the .NET Framework schedule.
In conclusion
DON’T PANIC
(in large, friendly letters)
LINQ to SQL will continue to work and EF will better address the needs of LINQ to SQL users with each new release.
In fact, I have a self-servicing class that all my L2S Entities inherit from and makes this scenario extremely simple and friendly for a developer to create fast, easily accessible data with plenty of robust data integrity.
By the time L2S is truly finished, there will be another solution, or the EF team will finally figure out how to adopt the L2S scenarios that make it so attractive. So for today, I am sticking with Linq to Sql instead of abandoning it in fear that EF will be the only solution.
In the past, I have usually blogged about PDC as it happens. This year there were so many things going on that I decided to wait until I returned to enter all the pertinent details for the VB Developer that were announced or shown at PDC.
Where do I start? There are several entries that I will be writing over the next couple weeks to cover these. In addition, some things I am working on are destined for publishing to another outlet, more on that when it happens.
One think I want to get out up front. The VB Language Team has a new leader, We will all miss Paul Vick and his invaluable contributions to the language as its leader for the past 10 years who will now move to "Language Designer Emeritus". Fear not VB Enthusiasts, his successor, Lucian Wischik will provide the forward thinking we need to keep VB.Net a great language and a terrific development platform.
I had the pleasure to talk with both while at PDC and my take away from conversations with Lucian, is that VB is in good hands and I expect to see great things come from his tenure as Language Specification Lead.
One of my first entries to come this week will be about something I have been working on that is only available using VB and XML Literals. I hope to provide some more insight into using VB in a practical sense to solve real-world problems in the coming months so stay tuned as these get posted.
VB10 is going to get some really important updates in the next release to further improve your productivity. Among these are array literals, collection initializers, automatic properties, implicit line continuations, statement lambdas, generic variance, and a feature that embeds primary interop assembly types in your assembly so you don’t have to deploy the PIA. There is also something coming for the Framework in general that make Parallel Processing really easy.
I will be writing samples on how to implement these in your general development over the next few weeks as we get the availability of a CTP that we can use.
Rest assured, VB.Net is not going away anytime soon and will remain my language of choice for all development. Rumors of the Death of VB are nothing more than false rumors or in some cases wishful thinking by language bigots.
Copyright © 2003-2004 H. Steele Price, IV -
All opinions are my own, not necessarily those of my employer, your mother, or any government agency.