ORM v. O/RM

When I was doing my undergrad in computer science, I spent a lot of time with Terry Halpin doing Object Role Modeling. We refer to it as ORM (think the "ohmmm" mantra, with an "r" thrown in!), though in industry the acronym usually refers to Object Relational Mapping. Whenever I think of Object Relational Mapping, or O/RM, in my head it's "The Dark ORM", just like The Dark Side of The Force.

In true ORM, you're taking a conceptual model of your business, or "domain", and using that model to help drive development. It's a very top-down approach to software development. This is great for when you're talking with business owners, trying to figure out how to build a system to support their needs.

In The Dark ORM (O/RM), whichever relational mapping system you choose (and there are many for general use, Java, or .NET) will look at the existing database and try to generate objects from the tables and fields. There are some very legitimate criticisms of O/RM out there, some even calling it the Vietnam of Computer Science (summarized here). This bottom-up approach is very popular among programmers because it lets them start building the system immediately. Once they have the data structure in place, they're able to generate large amounts of code; and, let's face it, that gives people very warm fuzzy feelings!

One of my side projects has been a local modeling agency, and currently I'm migrating some VERY ancient code that I wrote to a new system. In the next few posts I'll detail some of the procedures I've used to create the new site using both ORM and O/RM together as part of a model-driven development methodology.