2 Entity Framework Alternatives (or Give Me Data!)

Entity Framework has come a long way since version 1 — so much so that it leapfrogged every other version up to version 7.

With EF Core 2 out, I feel this gives us the performance and versatility we need for faster data access.

I firmly believe Entity Framework has become the de facto ORM (object-relational mapping) standard when dealing with data access in .NET, but that's just my opinion. More on that later in the post.

But some people don't feel the same way as I do, hence the reason for today's post.

Keep in mind that I'm not saying all of these are recommended; I'm merely including them as top ORMs I've found in the .NET community as possible replacements for EF.

I leave the evaluating of each ORM to the reader because, heck, I don't know what your requirements are for your project!

Dapper

Dapper was built by the StackExchange group. This ORM delivers amazing results since it leverages ADO.NET.

To give you an idea of the performance, Matthew Jones from ExceptionNotFound.net conducted a performance benchmark between Dapper, Entity Framework, and ADO.NET. His benchmark shows Dapper delivering exceptional performance over Entity Framework and narrowly edges out even ADO.NET.

While the performance is worthy, the technique on getting the data reminds me of the old days of retrieving data.

Here is a code example from their GitHub page:

public class Dog
{
public int? Age { get; set; }
 public Guid Id { get; set; }
 public string Name { get; set; }
 public float? Weight { get; set; }

 public int IgnoredProperty { get { return 1; } }
}

var guid = Guid.NewGuid();
var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });

Assert.Equal(1,dog.Count());
Assert.Null(dog.First().Age);
Assert.Equal(guid, dog.First().Id);

As you can see, it uses inline SQL to pull back the record and map it. The only thing missing is the left-to-right assignment.

Their GitHub page has a lot of examples like this.

NHibernate

NHibernate (introduced in 2007) is one of the oldest and most stable ORMs around and has been around longer than Entity Framework (introduced in 2008).

Most companies run their entire data access on nHibernate; it's one of the most stable ORM frameworks around.

I've heard tales of woe and tales of wonder with this product. It has a number of ways to configure your mappings, whether it be in code or through XML.

While I've never worked with the product, it's definitely vast in its configuration settings, making it quite versatile.

Example code:

//Add a Customer to the datastore

//'sessionFactory' is a thread-safe object built once per application lifetime (can take seconds to build)
//based on configuration files which control how database tables are mapped to C# objects
//(e.g. which property maps to which column in a database table)
//
//'session' is not thread safe and fast to obtain and can be thought of as a connection to the database
using (var session = sessionFactory.OpenSession()) {
//transaction represents a db transaction
 using (ITransaction transaction = session.BeginTransaction())  {
 //The line below adds the customer to NHibernate's list of objects to insert to the database
 //but it doesn't execute SQL insert command at this stage*.
 //*if the Id field is generated by the database (e.g. an auto-incremented number) 
 //then NHibernate will execute SQL INSERT when .Save is called 
 session.Save(new Customer { Id = Guid.NewGuid(), FirstName = "Boss", Age = 50 });

 //The call below will execute the SQL INSERT and commit the transaction
 transaction.Commit();
 }
}

//Retrieve the Customer from the database, modify the record and update the database
using (var session = sessionFactory.OpenSession())
{
 using (ITransaction transaction = session.BeginTransaction())  {
 //session's Query returns IQueryable<Customer>.
 //Only when .FirstOrDefault is called will NHibernate execute the SQL query 
 Customer customer = session.Query<Customer>().Where(c => c.Token == token ).FirstOrDefault();

 //Now the customer is 'part of' the 'session' object and NHibernate keeps track of changes
 //made to it 
 if( customer != null )  {
 //Changing a property of an object does NOT cause SQL to be executed
 customer.TokenVerified = true;

 //Committing the transaction results in an SQL UPDATE statement
 //NHibernate kept track of the fact that 'customer' has been changed since loading 
 transaction.Commit();
 }
 }
}

Replacing the SQL statements with LINQ makes this example better, in my opinion.

Why Just Two?

When examining the landscape of ORMs, I referred to a Wiki page with a listing of object-relational mapping software for .NET.

Now, I don't want to alarm anyone, but after looking through this list of ORMs, I realized that 75% of them were names I've never heard of, don't exist, or aren't active.

I tried to remember some ORMs my colleagues used in the past. I remember the majority mentioning Entity Framework and NHibernate as their tool of choice, with Dapper being the new guy on the block (in that order).

Even though Dapper is new, I couldn't find any other mature, solid, stable, or popular ORMs.

Is Entity Framework the ORM to use in your projects?

Conclusion

In that list, a select few ORMs are either fading away or inactive and the winners are holding their place in the .NET community.

But for how long? Even though they're relational, how much time do they have? Are they on borrowed time?

Could it be that "relational" is starting to dissolve and documents (JSON, XML, CSV, or TXT) are becoming the preferred mechanism for storing data?

Each ORM has a specific feature set for developers to complete a project in a specific way. Personally, I feel grabbing data is grabbing data. No matter how feature-rich, it basically comes down to performance.

With that said, my second requirement for a good ORM is maintainability/ease of use.

I'm not too keen on SQL statements ("magic strings") in my C# code, either. If you aren't using Stored Procedures, it almost like the Reese's Cup dilemma ("You've got your SQL in my C#!"). You run the risk of finding errors at run-time instead of compile-time.

I hope these ORMs provide an approach and feature-set that you and your company can be happy with when the project is complete!

Did I miss an ORM? Do you have a favorite? Are ORMs starting to dissolve? Post your comments below and let's discuss.