Let's face it: if trends continue, some form of ORM will be a fact of life at most .net organizations that develop business / enterprise software. Microsoft isn't playing games this time with Entity Framework. They mean for it to succeed. Additionally, at the time of writing this, NHibernate has been downloaded 391,024 times from sourceforge alone (there is more than one place to download it from). This being the case, I’m going to give everyone a few pointers to ensure that their first attempt at ORM fails.
Here are my tips to insure ORM adoption failure (in no particular order):
Consider the ORM’s SQL engine as a replacement for SQL knowledge. The whole point behind ORMs is so that I don’t have to write or understand SQL right? WRONG!
Consider the ORM’s SQL engine to be a black box. I got back the correct dataset, so this must be the best SQL the ORM can produce right? WRONG! Most ORMs will create drastically different SQL depending on how the object query is structured.
Don’t get more than a skin deep understanding of the ORM. If you run into a brick wall with a bit of behavior from the ORM, you can follow two paths. You can A) learn about the finer points of the ORM to resolve the issue, or B) rip the ORM out of your application. The latter is the outcome I’ve seen more often than not. A classic example of this is the N+1 select issue where the app calls the database in a loop. ORMs have things such as eager loading, multi-queries, and future queries to avoid extra trips to the database. However, it’s best to ignore the existence of those features if you want to fail at ORM.
Use ORM generated schema without manually tweaking it. Many ORMs will happily create a schema for the developer just how they specified it, and index free. Ideally you shouldn’t use generated schema at all once you are up and running. A DBA should be creating a schema using relational theory. However, if you want to fail, it’s best to just used that generated schema.
Use the ORM for 100% of your data access.
Most ORMs allow for dropping into prepared SQL, stored procedures, and even db function calls. However, it’s best to ignore this functionality if you want to fail.
Maintain OO purity at all costs.
Does fetching your aggregate root cause an 11 table join? So be it.
Cut the DBA out of the development process.
The whole point of ORM is to cut out the DBA right? WRONG! The DBA should be just as active with helping to craft the data access strategy as they would with a hand rolled data access layer. Cutting the DBA of the picture is a recipe for failure.
Don’t profile your application.
If you want to fail, it’s best to find out if you have have created a SQL nightmare once you hit production. NHProf, EFProf, L2SProf, and SQL Profiler are your friends. Ignore them to fail.
I hope you find these tips helpful. I’d like to hear about any other tips for ORM failure you might have.