Tips for ORM Data Access

In my last post I took a stab at Lazy Loading data access, and pointed out a concrete example of why I don’t like it. As with anything there are trade-offs. Here are a few practices I use for clean and fast data access. They are heavily influenced by some common patterns from PoEAA, and Domain Driven Design.

  • 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

13 thoughts on “Tips for ORM Data Access”

  1. I don’t agree with avoiding lazy-loading. You can have your cake and eat it too by exposing explicit graph loads via things like Fetch.

    The problem with DTOs and the like is type transference where once you flatten an object you need to manage when that flattened entity needs to be re-retrieved as a “real” entity.

    For example I may pull a list of lazy-loaded objects, then when I go to the details page I may very well decide to fetch all “child” objects that make up the composition at once if I know I’m probably going to be hitting most of the data anyways. I don’t really want to be dealing with different objects that represent different views of the same data.

    As for situations where = a.b.c.d{.name} I don’t think there’s anything wrong with exposing commonly used “optimizations”. I.e. = a.dname, where dname = Nothing more than a simple assertion test is required to assert that a.dname doesn’t start to mean something different to

  2. Another approach I’ve tended to favor over the past few years is the following:

    Don’t use ORMs.

    Applying the ER model will make you a better OO designer.

    Modeling it yourself will encourage you to be sparing; you’ll gravitate towards 3rd normal form where appropriate.

    Modeling it yourself will reinforce your understanding of the underlying problem domain which will result in a leaner OO model.

    Visual DB design tools = good (no point futzing around with DDL all day).

    Object to Relational mappers = bad. They leak and they’re brittle. They’re an overapplication of the OO metaphor.

    SQL is good. SQL is easy. Specifying the what is easier than specifying the how.

  3. Your post is great, very appealing to me, have helped me the most, let a person can gain a lot of different things. Support for you.I have about sports, very cheap Nike shoes, and I hope to help you.[url=]cheap nike shoes[/url] [url=]timberland men boots[/url]

Comments are closed.