So I’ve been evaluating different ORM’s and I’ve decided to stick with Entity Framework. I’ve done some testing with NHibernate and discovered that it is very difficult to get running. I still need to spend more time to research NHibernate, but for now I think I’ll just run with Entity Framework. One of the positives of EF over NHibernate is the visual tool that makes it easy to setup the data objects. Our company is planning to employ interns starting in the Spring of 2014 and I’m thinking forward along the lines of using the KISS principle wherever I can. Later, when things are moving again, I can take another hard look at NHibernate and determine if we want to switch to that ORM over NHibernate.
So Friday I began the tedious task of converting one of the LINQ-to-SQL subsystems to EF. Most of it went smoothly. We don’t currently have a lot of data access using an ORM, so now is the time to determine which tool we’re going to stick with. In order to get around the namespace weakness of EF, we are going to put our database access inside it’s own project or subdirectory. Our code will need to share tables that will be defined in one place. I think the ability to refactor will assist us in weeding out deprecated tables and fields in the future.
One of my co-workers made me aware of an article called “Performance Considerations for Entity Framework 5″. This is quite lengthy and very detailed. I would recommend putting it on your “favorites” list and keep it handy when you’re ready to use EF. This article talks about EF version 5, but I’m sure they’ll update it for version 6 soon. Here’s an interesting side article for unit testing and mocking EF6: Testing with a mocking framework (EF6 onwards).
So What’s the Point of Using an ORM?
Speed is not necessarily the only reason for using a different data access model. In this case, the point is to catch SQL query mistakes at compile-time. In the good-old-days when queries were sent back to the database as a string, any errors in SQL were only detected when the query executed (i.e. run-time).
ORM’s create objects that represent the tables, fields and other components of the database so that the developer can write a query directly in code (like C# or VB). The SQL statement written in code can have automatic syntax highlighting for errors and errors are detected at compile time. Of course, it’s still up to the software developer to write a correct query. At least this is one more step in reducing the amount of troubleshooting time a developer must take to get the software right.
Unit testing is the latest new-hotness. Technically, unit testing has been around for some time (so it’s not new, but it’s still hot). In EF6 there is support for in-memory database mocking that can be used to test parts of your code. In the past I have used test databases that I generated in a local copy of MS SQL server. Using a test database means that I had to generate the tables and then tear them down when I was done. By creating data in memory, the whole process takes less time and resources.
The reason why unit testing is so important in this instance is that many web applications are mostly database queries. I know that the software that at my current company contains mostly code to access and manipulate data. So unit tests that don’t test the queries that access the database are very limited.
I’m currently looking at the unit testing and mocking of EF described here: Testing with a mocking framework (EF6 onwards). Specifically the “Testing query scenarios” section. If you’re using Moq, make sure you download the NuGet package for Moq (it’s not included in the base install of Visual Studio 2012). I’m hoping to be back with an example soon. Stay tuned…