Tips for ORM Data Access

Data Access should be one of those problems that must be solved in software development a long time ago. Getting and putting data from a database was done 10 years ago and is still done today. But we keep struggling writing code to talk to our databases. Object relational mappers (ORM) are one step closer to writing more business oriented code and less infrastructure.  As an ORM is only a tool and not the solution, Jarod Ferguson posted following tips to help you implementing ORM right:

Retrieve data by aggregate roots, have a repository for each root. The root queries should return the entire aggregate. If you are going to defer loading to a part of the root graph, be explicit. Instead of lazy loading Foo.Bars, I like to say Foo.LoadBars() <- yes seriously

Learn how to identify the right aggregate

Respect your aggregate root boundaries. Aggregates cannot call into other aggregates children! You shouldn’t be adding a product from the order, really, this is bad: LineItem.Product.Calatalog.Add(new Product). The order AR just crossed into the Catalog AR. Its not the job of the Order to add products to the catalog

Do not try an overuse an aggregate, its ok to create a new one. Less is more does not apply. Fulfilling an order is different than placing one, and your data access may need to reflect that

Use a ‘Read Model’. The most common approach here is using DTO or ViewModel, and projecting straight into it from the object model query or database

For complex queries that perform aggregations and calculations, consider using a store procedure. They really have their place, even with the best ORM’s (then project into Read Model)

Avoid putting query logic in mappings (Assembler’s, Translators, AutoMapper)

Use a tracing tool. I like the SQL trace profiler, but if you are not as comfortable with sql, there is a some good profilers around, like NHProf for nHiberante & soon EFProf for the Entity Framework

Know the SQL that is going to your database. Have your tests emit the generated sql out to the console. Live it, learn it, love it. You should know your ORM tendencies, especially if you are using a linq provider

Batch requests to your services and database, especially if you are in a web or distributed environment

Jarod continued his Data Access Tips post with a more detailed explanation about DTO's, DDD and the Anemic Domain Model.