In-Depth

.NET Survival Guide: Data Access Technologies

• By Mark Michaelis
• 01/01/2011

Data Access Technologies
The frequency with which Microsoft has changed database access technologies is remarkable, with each new scheme offering the promise that .NET developers have finally arrived at a long-term solution. The core problem with the .NET Framework was that although there was a strong database access technology provider in ADO.NET, it failed to deal with the key pain point for developers: object-relational mapping (ORM). Specifically, how the data represented in an object-oriented programming language such as C# or Visual Basic .NET serializes into a relational database. Although there were numerous solutions available in 2007, none truly dealt with the problem of eliminating the need for SQL and of SQL schema seeping into the client-side programming language.

Visual Studio 2008 and the .NET Framework 3.0 changed this situation radically. For the first time mainstream .NET development had a superb mechanism, in the form of LINQ, for programming the object-relational impedance mismatch. Although Visual Studio 2008 presented two database LINQ solutions -- LINQ to SQL and the Entity Framework -- Visual Studio 2010 addressed this ambiguity with the Entity Framework 4. Microsoft has essentially deprecated LINQ to SQL. Though Prominent ORM alternatives exist in NHibernate and LLBLGen Pro, the Entity Framework 4 has emerged as the most logical data access target for .NET developers. This leaves developers with four prudent options when developing under the .NET Framework 4:

• Leave existing development on LINQ to SQL but search for an opportunity to migrate to the Entity Framework.
• Leave ADO.NET development in place, but capitalize on any opportunities to implement with the Entity Framework.
• Commit to using the Entity Framework by default for database-access development going forward, outside of exceptional cases.
• Consider widely deployed alternatives like NHibernate and LLBLGen Pro, which boast features and support that rival those of the ORM technologies coming from Microsoft. Prior to the .NET Framework 4, gaps in the first version of the Entity Framework made it a less-than-perfect solution. Microsoft has resolved many of those shortcomings with the Entity Framework 4. Among the significant new features making the Entity Framework 4 a credible data access target:
• Foreign Key properties on entities allow for accessing data associated with foreign key relationships.
• Plain Old CLR Objects (POCO) can be generated, using online templates, so that no special entity framework derivation or attribution is required.
• Text Template Transformation Toolkit (T4) Code Generation enables deep customization of the entities that are generated from the database, and the ability to even generate the database given a set of POCO objects.
• Lazy Loading, enabled by default, doesn't load an entire object or its graph until the code actually uses it.
• Improved stored-procedure support, which is accessed through member functions on an entity, allows for such features as returning complex types from stored procedures.
• Enhanced support for entities that are disconnected from the Entity Framework context and possibly transferred across WCF boundaries -- even with support for change tracking within the entity.
• Inclusion of interfaces like IObjectSet that enable the development of mock data layers.

These new features, all of which are very significant to the vast majority of database development scenarios, provide a compelling narrative for the Entity Framework 4. In addition, Microsoft continues to provide interim community technology previews of future enhancements slated for the Entity Framework.

In Summary
After some fits and starts, Microsoft has landed on a viable target for .NET data access in the form of Entity Framework 4.