New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Linq to SQL will live on...

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:

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.


Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Davies (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out