ORM in .NET

13 November 2009 | No Comments » | admin

 

Introduction

ORM, or object-relational mapping, is one of the tougher things to accomplish in modern, object-oriented programming languages. It involves moving away from the traditional data store paradigm: there is no (or very little) dedicated, pre-compiled code involved in reading/writing an object to/from the database or other backing store. Instead, the logic involved in accessing the backing store is determined at runtime using a combination of reflection and attributes that decorate the business objects in question. Many projects and frameworks have been created to try to address this concept, with varying degrees of success. What this article covers is a general introduction to ORM concepts, the approach that .NET 3.5 takes.

In the beginning…

Prior to .NET 3.5, you had several choices when it came to getting your business objects to and from the database:

  1. Roll your own – This means you don’t use any frameworks and don’t auto-generate any code. The database schema and the .NET classes are created by hand, as is the data access layer. While this will provide the ultimate level of customizability and performance, it’s tedious (involves copying a lot of boilerplate code), error prone, and difficult to maintain when the objects or the database schemas change.
  2. Auto-generate the classes and the data access layer – This is where code generation tools like CodeSmith or MyGeneration come in: you point them at your database and it will generate the .NET classes and the data access layer. Like option 1, this isn’t true ORM: you still have pre-compiled code responsible for accessing the database to read or write an object’s data. However, its automatic generation of the code is a step in the right direction, removing the error-prone human factor when creating the classes and the data access layer.
  3. Use a true ORM framework – There are several well-known ORM packages available for previous versions of the .NET framework, including NHibernate and Gentle.NET. As mentioned previously, ORM removes the dedicated data store code and inspects an object at runtime to determine what it needs to do to read/write it to/from the database. Attributes are used to decorate the class and its properties to give the framework pointers about where things go in the database. The actual SQL for an operation is generated dynamically based on these attributes. There is often a code-generation component in these packages that generates the .NET business object classes from the database schema, but no dedicated data access code is generated

Some Problems with ORM

So all this dynamic, runtime SQL generation stuff sounds great, right? Not so fast: ORM has several serious drawbacks. The first of these is performance, as you’re going to encounter a slowdown any time you bring reflection into the equation and start dynamically generating SQL. ORM will never be as fast as rolling your own: there’s no substitute to being able to hand-tweak your stored procedures and pre-compile all of the data access logic. Another drawback is that ORM doesn’t deal well with extremely complex databases. When designing complex databases with a lot of constraints and relationships spanning several tables, it’s often necessary to include intermediary tables to link various entities together that is great from a RDBMS standpoint, but doesn’t translate all that well to an object-oriented environment. This can lead to obtuse and difficult to understand auto-generated classes. Keep in mind that RDBMS and object-oriented environments are fundamentally different, and each includes its own set of design and performance considerations. What works in one environment is not necessarily optimal for the other environment. That being said, the upside to ORM in terms of maintainable, clean, and easy to understand code can be quite compelling, provided that it’s used correctly.

ADO.NET Entity Framework in .NET 3.5

So, now that you have a good idea of what ORM is all about and its potential pitfalls, let’s delve into how Microsoft approached this concept in .NET 3.5. It takes a different approach to the challenge of ORM by not focusing on slaving the object model to a relational model, but by instead giving us an entirely new way to access and query our data that’s not limited only to relational data. With this approach, the ORM capabilities of .NET 3.5 evolve almost as a side-effect instead of being the prime focus of this new data access scheme. 
 

The ADO.NET Entity Framework is designed to enable developers to create data access applications by programming against a conceptual application model instead of programming directly against a relational storage schema. The goal is to decrease the amount of code and maintenance required for data-oriented applications. Entity Framework applications provide the following benefits:

  • Applications can work in terms of a more application-centric conceptual model, including types with inheritance, complex members, and relationships.
  • Applications are freed from hard-coded dependencies on a particular data engine or storage schema.
  • Mappings between the conceptual model and the storage-specific schema can change without changing the application code.
  • Developers can work with a consistent application object model that can be mapped to various storage schemas, possibly implemented in different database management systems.
  • Multiple conceptual models can be mapped to a single storage schema.
  • Language-integrated query (LINQ) support provides compile-time syntax validation for queries against a conceptual model

LINQ in .NET 3.5

How do they do it? LINQ. It stands for Language INtegrated Query and Microsoft wants it to be THE way that you sift through data in the .NET framework. Its structure will be immediately familiar to anyone with experience writing SQL statements and it marries the simple yet powerful query syntax of SQL to the strong typing of an object-oriented language. The real kicker, however, is that it’s not limited to relational data: anything that implements the IEnumerable and IQueryable interfaces can be used with LINQ. Here’s a quick example so that you can get an idea of what it’s capable of:

C# Code
01.List<string> elements = new List<string>() 
02.{ 
03.  "Iridium", 
04.  "Einsteinium", 
05.  "Polonium" 
06.};
07.IEnumerable<string> results = from element in elements
08.                  where element.Contains("n")
09.                  select element;

It’s just a simple search of a generic string list instance for elements that contain the letter “n”. Whereas before you would have had to accomplish this imperatively, that is, you would have had to write code to iterate over the collection and drive the search, you can now accomplish the same thing declaratively. Basically, you’re stating what you want to do instead of how to do it. While the syntax takes some getting used to, this approach is inherently less error-prone. It also bears mentioning that Intellisense is in full effect in the above sample, so you lose none of the “ease of use” features of Visual Studio when you employ LINQ.

  • Share/Bookmark