As I worked on the Silverlight Dashboard application I knew I would have to do a few data access tasks. Using Linq to SQL I was able to create the entire data layer in 5 minutes. The code to write to the data layer took a total of 20 minutes. On average I can write a Linq query in 1-2 minutes (because most of it uses intellisense and you simply hit the Period key, type the first letter and then hit the Tab key).
As I was working I thought to myself "Would Microsoft really take away a tool that was this great?". Today I ran across this blog post:
http://damieng.com/blog/2008/10/31/linq-to-sql-next-steps
and it appears everything will be fine. It's safe to continuing using Linq to SQL (be sure to read his comments in the comments section at the bottom of his blog post).
I have looked into Linq to Entities but as of yet I have not figured out how to get it to work when you export a DotNetNuke module and install it on another site. Even when this is resolved, I am still faced with the question of why would I want to stop using Linq to SQL that works great?
Linq to Entities offers a level of abstraction. Abstraction can be helpful but you pay a price in complexity. I fought for the DAL+ because I felt that the abstraction of the full DotNetNuke DAL made it too difficult for new developer's to create DotNetNUke modules (and that would not be in the best interest of the community). So when I hear the words "this offers a level of abstraction" I don't automatically get excited. I want to know "What benefit does this abstraction provide me and is it worth it?".
So far the only benefit I see is that my "People_Data" and "People_Details" table can be accessed in one "People" class. Also Linq to Entities works with databases other than SQL server.
Neither of these issues is compelling enough for me to pay the price of having to design and maintain this additional layer of abstraction. The biggest problem with any abstraction layer is you have introduced additional points where you can have an error (for example the mapping of a field is correct on one side of the abstraction but wrong on the other side).
As soon as I determine that Linq to Entities offers something better that makes the price something I am willing to pay (and I get it to work with DotNetNuke) I will start using it. For now I will enjoy spending only 20 minutes writing data access code and know that my Linq to SQL code will still work for years to come.