Microsoft's products LINQ to SQL and Entity Framework have provided another options to the ORM users/implmenters. These products are unique and different from existing ORM's and it would be interesting to see how it distinguishes itself.
Objective:
To learn about LINQ to SQL and EF and their pros and cons and usage scenarios.
Introduction and background:
In this era of software development, many would be aware of ORM (Object Relational Mapping) tools. The relational model entered into world of data in 1070’s.The object oriented model is present from the days of C++ (1970’s) and become more prominent with Smalltalk and Java. With .Net it has become omnipresent. The incompatibility in type systems in the object oriented languages and database model has given rise to need of something to serve as mapper between them and this is where ORM comes into the picture. ORM can be termed as programming techniques or method for converting/transforming data between incompatible type systems in relational databases and object oriented languages. ORM appeared on the screen in 1990’s which has resulted from long time research in this field. Hibernate is popular tool for java and NHibernate is meant for .NET. These are open source tools. There are other tools like subsonic etc. Microsoft hit the scene with LINQTOSQL and it now offers the ADO.NET Entity framework (EF) too. So these are two products which are available for developers to tie the relational data and object oriented programming, together.
Let’s have a quick look at the (desired) features of ORM
- Mapping the object/s and relationships: 1:m (one-to-many), n:m(many-to-many) and m:1(many-to-one)
- Transaction and concurrency management
- Queries or querying ability
- Performance:
- Lazy Initialization
- Batch Fetching
- Caches/persistence
LINQ stands for Language-Integrates Query. It encompasses a set of features that let you retrieve information from a data source which may be an array, objects collection, XML files, Active Directory, Outlook & ADO.NET Datasets and best part is the syntax used to query data in a relational database is the same as that used to query data stored in above said data stores.
In this discussion, we are going to focus on LINQTOSQL and EF and learn the scenarios where to use what.
Description:
With LINQTOSQL, Microsoft took first step towards providing ORM. Let’s have brief understanding about LINQTOSQL and EF
LINQTOSQL (L2S)
- LINQ to SQL allows a developer to embed queries in C# & VB.NET to access MS SQL Server
- LINQ to SQL uses Data Context to query database.
- One can use LINQ to SQL designer to map database columns to Entity class properties. Also external XML mapping files can be used.
- LINQ to SQL is also called as DLINQ because compiler parses the query, performs type checking, and compiles query in to expression tree. For LINQ to SQL expression tree is then parsed in to a SQL statement.
Entity Framework(EF)
- LINQ to Entity or EDM is next step of LINQTOSQL and focuses on entities
- It is different from normal ORM because it provides additional features like entity inheritance, entity composition & flexible, loosely coupled three tired model consisting of the conceptual model, the mapping layer, and the storage model.
Comparison: The prominent differences are enlisted below which can give a real good idea of what is what.
|
Point of Differences |
LINQTOSQL |
Entity Framework |
|
Database compatibility |
Only with SQL server |
Also with Oracle, DB2, Informix, MySQL, Postgres, etc. |
|
Modelling complex types |
Little difficult and contrained |
Data Store agnostic models |
|
Querying |
LINQ |
Database independent Query Capabilities using LINQ or Entity SQL |
|
Client |
NA |
EntityClient with EntityConnections, EntityCommands and EntitySQL |
|
Returning types |
Objects |
Objects and streamed data if EntityClient is used. |
|
Model First or Code First |
No |
Yes |
|
Mapping many-to-many relationships |
Requires that an intermediary class map one-to-many to each of the classes that are party to the many-to-many relationship.
Table per Subclass,
|
Allows a direct mapping of many-to-many relationships with no intermediary class |
|
Control over number of database round trips |
No exclusive control |
The developer has full control over the number of database round trips by explicitly specifying when to load such information from the database. |
|
DataContext |
Yes |
No |
|
Support for UDT – custom types |
No |
Yes |
|
Usage |
Through data context and stored procedures |
Entity Client like our SQL Client
LINQ to Entity(with Object Services or Entity Client)
Object Services |
Usage Scenarios: Let’s discuss the scenarios to help us decide where to use what.
|
Usage Scenario |
LINQTOSQL |
EF |
|
ORM solution for Microsoft SQL server |
X |
X |
|
ORM solution for variety of database servers (SQL CE, Oracle, DB2, Informix, MySQL, Postgres etc. |
|
X |
|
Existing POCO (own plain CLR classes) rather than generated classes |
X |
|
|
ORM solution with performance optimization through stored procedures and compiled queries |
X |
X |
|
Define domain model from scratch and use them for persistence layer |
|
X |
|
ORM solution with 1:1 with object model |
X |
|
|
ORM solution with classes may be 1:1 with the database or may have a very different structure from the database schema and also with inheritance hierarchies that may have alternative storage schemes (single table for the hierarchy, single table for each class, single table for all data related to specific type) |
|
X |
Summary:
We discussed the parity in object oriented world and relational models. The need of ORM was pinpointed and also it features are highlighted. Microsoft’s products LINQTOSQL and EF were elaborated with the differences, comparisons and also the usage scenarios were put forth.
Conclusion:
With Microsoft establishing into ORM arena, the developer fraternity have got more options in hand in addition to existing ORM solutions. Definitely to choose ORM solution for particular situation is a challenging job and involves many parameters to decide upon. To help arriving at ORM solution, the usage scenarios are mentioned. Non-Microsoft ORM solutions are out of scope for this discussion.
It can be easily concluded that if there are no existing ORM in one’s system and also there is need of domain model (having potential for re-suability), then EF is the choice to make. Even for existing ORMs (Non-Microsoft) EF can be chosen looking at the future direction (towards data model) of EF.
Definitely, EF has yet to mature to the extent of other ORM’s but as mentioned considering future direction and being native for .Net applications, it could be the choice to settle for.
References:
http://msdn.microsoft.com/en-us/library/0f66670z(v=vs.71).aspx
http://msdn.microsoft.com/en-in/magazine/dd264793(en-us).aspx?pr=blog
http://blogs.msdn.com/b/dsimmons/archive/2008/05/17/why-use-the-entity-framework.aspx