OO data model - can I ignore Object Relational Mapper constraints?

Question

I am just starting to model the data for a new C# project, which must be persistable.

Looks like the most natural OO model will have lots of nested .Net generics. Lists of objects, and these objects will also contain Lists of other generic types, and so on, nested at least three levels deep.

Ideally, I'd like to just design the data model in an OO fashion, and let an Object Relational Mapping tool handle the persistance - for me, OO design comes much more easily than relational design.

But my initial research into ORMs indicates that they don't neccessarily work this way. It's not clear to me yet if I can just create any arbitrarily complex object model, and expect the ORM to persist it, "automagically". (I asked that question yesterday).

It's my impression that I may have to limit my OO data model to constructs that I know the ORM can handle, which seems like a big limitation, especially when I haven't decided on an ORM yet.

I want to keep the project design moving forward, and don't want to get bogged down in researching ORMs right now.

My instinct is to just design my object model around what I know I can do in C#, in the way that seems most natural. This will help me get a better feel for what is really required for the application. It's my hope I can then re-factor the design based on ORM limitations, if that proves to be necessary.

Is this a good approach, or am I setting myself up for a world of hurt? Is it better to deal with known ORM contraints up front, and "dumb down" the object model around those constraints?

Edit: Unsolicited, Stefan Steinegger listed most of the contraints that NHibernate imposes on the OO code. Can anyone else provide a similar list for other ORMs - Subsonic, in particular?

Answer 1

I don't know too much about other ORM's, but you should certainly go that way with NHibernate. It's intended to be used exactly like so: First design your domain in a DDD fashion, care about database and persistence-related stuff later. It might be that some (minor) refactorings become necessary when introducing NH, but they are in my experience not a big deal, if you have a properly designed domain model, and they are certainly not painful.

Answer 2

I think the real question is how can I develop my OO application and still being able to persist its data (objects) in a relational storage, regardless of ORM or no ORM. You should be OK with your approach of being concerned strictly with your object model until you reach real volume, where the impedance mismatch may hurt you. It is still not possible to develop any relational database backed system without thinking about the system's relational model, be it OO or not.

Also, the only classes in your object model that need to be "dumbed down" are the ones subject to persistence. All others can be as complex and sophisticated as you wish.

Answer 3

To decide how easy it will be to map you model to a relational database still highly depends on the ORM which will be used.

I've some experience with NHibernate. It is the most flexible and non-intrusive ORM I saw until now (although I didn't see many of them). So I can talk about NHibernate, even if you won't use it, it will give you some impression of what you should expect.

We almost freely design the class model. The limitations are more in the implementation details:

• you need a default constructor (could be private)
• collections must be of type IList<T>, ICollection<T>, IDictionary<K, V>, Array, a few other interfaces or its non-generic counterparts.
• everything needs to be virtual to make lazy loading possible. (optional, but highly recommended)
• every entity (non-value-type) needs a database primary key property and a database version property for optimistic locking (optional, but highly recommended)

You should be careful when having value-type classes (not having an own identity and treated "by value") which are polymorphic. The must probably need to become entities (needing identity) to make this possible.

I can't remember any other limitation we had in NHibernate concerning the class model.