Initially the view is 1:1 with the underlying table. As the two start to diverge, the view corresponds to the entity (the logical data model as we used to call it) and the table is, well, the physical data model.

Of course, historically views have been for read-only access or very limited update access. But most RDBMS vendors (all the commercial ones) anyway, support INSTEAD OF triggers on views.

To my mind this seems like a much more natural place to put the abstraction layer (as and when you need it). And it allows DBAs to easily do impact analysis when they want to change the physical database schema.

Cheers
Dan

At the moment, I am buying into the concept that your domain model shouldn’t know anything about other services – including how it is persisted. Exposing save, find etc operations on the models, as the ORMs do, breaks that concept.

You may have extra pain mapping between your domain and ORM models but just how much, I’m not sure.

@clinton – that sounds interesting…go straight for SQL. Then again, the ORM does make life easy to start with. Having said that, I find that often you usually need to tune your queries with ActiveRecord (rails) anyway.

@david – yes, that is a powerful thing, iff you a building a database-table-on-the-screen application. For anything more, you tend to start cursing AR (and sometimes DHH’s attitude).

@toby – the way I see databases diverging from the model is in how you store the data. I am mainly referring to the times when you need to tune your database for performance reasons (putting indexes, normalizing your tables etc).

@sai – the butterfly effect maybe?

(@ben – you know we basically had this on our last project).

How does your example deal with object graphs? You don’t want to traverse the entire aggregate copying values just in case, do you? And can you do lazy loading?

I’d love to know a real example of a problem that you are trying to solve with this solution that couldn’t be solved by fancy mapping in Hibernate or even a special-case repository method that drops down to raw SQL.

You know what I really, really want? A framework that does all the fanch-shmancy stuff with object graph management and cleanliness tracking that a sophisticated ORM does, but just give me call-backs for dirty objects rather than persisting changes to a database. Then I really can have persistence as a view and ensure that all the views in my complex thick client get updated at the right time.

Ben

P.S. It is odd and freaky that many TW people think alike. This experience is happening to me for the third time

The responsibility of what data resides in which model does not belong to my persistence code. It belongs to my domain model, solely.

I also don’t buy the idea that the database must eventually diverge from the domain model. The only way I see that happening is when other applications integrate at the database layer, positively the worst place to do that sort of integration.

Work hard to keep your data model in line with your domain model. Resist the temptation to let others put their grubby hands down your data pants. Do that, and the motivation to keep DB Schema and Domain separate may fall away.

Thanks for the provocative entry, keep it up.

Toby

But it seemed to me that the main advantage of Rails was that if I was willing to let the ORM model drive everything in both directions, Rails would happily take most persistence tasks and most of the “C” tasks in “MVC” (at least for basic use cases) off my plate. Unfortunately I was starting from a pre-existing database, so it wasn’t quite that easy, but that seemed to be the general idea.

Since I come from a Java background, and I’ve been through everything from SQL-in-the-JSP to entity beans to home-grown SQL abstraction libraries to Hibernate and back, I totally understand where you’re coming from, about the model and the database evolving in different directions. But I guess what I’m wondering is, how much of what’s good about Rails do you keep, when you stop letting the ORM model drive?

This is an interesting blog post for a couple of reasons. First, because I think this is a phase all developers go through… that of over abstraction. If you separate your domain model and your “ORM model”, and similarly you’ll probably have a form model for your web framework because you’ll eventually decide that you need a place to put lists of optional values or non-domain related form fields (e.g. “remember my username”). Then you’ll find yourself marshalling from the web to the form, loading domain objects, mapping them to orm objects, and finally persisting them to the database. Then one day someone will want an XML format of your domain and you’ll need to serialize it using XStream or something similar, but then where do you put your SOAP envelope? PHEW!!!

Suddenly you’ll have the 7 layer cake design that cost so many applications their success. I saw Rails as the counter to this design, with its relatively flat design… the “smart object” design, where the domain is everything (from validations to web form fields, to mapped persistence fields etc).

Anyway . The second reason I find your post interesting is that I agree with your statement that eventually, even if you begin with full control of your database, it ultimately diverges in its own direction. This usually happens once your application is successful and people start to notice that your database contains useful information. And along comes “Application B” — the other application or 3rd party tool that is built in some other language and expects completely different things of your database. All of a sudden the database is no longer your own.

So you’re absolutely right to feel that disconnect early. However, the solution of using two layers of classes might be overkill (or just “kill” or perhaps “certain death” I fear you’ll regret that decision in the long run.

A better solution is probably just plain old SQL and a good domain model, and a web framework that lets you wrap natural domain objects with forms (like Stripes). This keeps you to a single domain, a light web design and a flexible persistence solution. And about half as much code as you’re about to write.

I’ve always said, a project may start with ORM, but it will end with SQL.

All the best,

Clinton Begin
Former ThoughtWorker

I think that you may have better luck using an object database than trying to slap a bunch of duct tape over relational database.