Migrating from 'native' OODBMS to ORM (Ent

Question

A while ago we started developing a new project which internally has about 25-30 different classes/types/models that are heavily related to each other either via 1:n, n:m or n:1 relationships.

Back then we went with a native .net oodbms system basically because what it allowed us to do was to take our object model and simply add a few persistence related methods(-calls) here and there and we were ready to go. However, over time we ran into more and more caveats, really bad, non-fixable (within a reasonable timeframe) limitations that forced us to implement slow workarounds resulting in mediocre performance and scalability issues on the horizon and license fees have almost increased by a factor of 5 for us with no change on our end (they got bought by big inc.).

Therefore we're currently starting to look for a long-term solution in terms of scalability/performance as well as maintenance. We had a look at other "real" oodbms'es and always came across major breakers for us and therefore we started to look a little further and basically are thinking about ORMs now, which hopefully let us keep most of the focus on our objects instead of wrangling with SQL.

So basically here's my Question: does anyone have any real-world experience with Microsoft's Entity Framework or any other .NET ORM that keeps configuration as maintainable as possible as well as performs well in closely/heavily related entities? The amount of data we store is not amazing or extensive in any sort (we expect a total of 100k instances across all entities within the next 3 years).

Does anyone have any ideas/suggestions for an ORM and/or experience migrating from an oodbms to rdbms?

Answer 1

As you have an existing object model and you are looking to migrate to an ORM solution then I would say NHibernate would certainly be a good choice. Here's why:

1. You won't have to make (m)any additions / changes to your domain model classes to support persistence. NHibernate goes a long way towards supporting persistence ignorance in your domain model, although you may find you need make some minor changes such as marking more methods / properties as virtual than you otherwise would for example.
2. After mapping your existing object model, you can generate the schema for your database. This is a huge time saver for domain driven (or just object-model first) development. This functionality is supported via the FluentConfiguration.ExposeConfiguration() method with fluent NHibernate or via the hbm2ddl tool with standard NHibernate mapping files. This also helps, of course, with maintainability - changes to your object model can be quickly reflected in your database schema.
3. Using fluent NHibernate for mapping helps to make the initial mapping quite fast as you get autocomplete and a simplified mapping model. This will also help to give you the maintainability you are looking for - your mapping is declared in code with fluent NHibernate, so refactoring tools will change your mapping accordingly. You may also find that you can use Fluent NHibernate automapping and avoid manually mapping your object model for the most part.

Using Entity Framework for this will be more challenging. While entity framework is a capable ORM in many respects, it is not as mature as NHibernate and there are a few reasons in this case specifically why I think it's probably not the best choice:

1. You will have to make a lot of changes to your existing object model to support Entity Framework. If you want to use the currently supplied tools for entity framework you will probably need to migrate your code to generated partial classes which inherit from the EntityObject entity framework base class. This inheritance requirement may or may not be a problem for you depending on your existing object model. You could avoid this by supporting some interfaces in your code but this is non-trivial and I think you will lose a lot of the built in tooling support for managing your mappings.
2. You will almost certainly need to manually create the database schema. With a good sized object model this is typically not an insignificant task.
3. The entity framework does not support transparent lazy loading out of the box. I'm sure transparent lazy loading is something you are used to with an OODBMS, and it is supported by most other ORM's (including NHibernate of course), but with entity framework you will find that you need to explicitly .Load() related objects (both parent and child relationships) before you reference them in your code. There are workarounds for this (e.g. this one), but it's not a built-in feature.

Overall, in my opinion, for object-first development, or where you are trying to leverage an existing object model, NHIbernate is a better choice. For data-centric developments, the Entity Framework (or linq to sql or even subsonic) become more viable choices.

You may also want to evaluate commercial ORM offerings such as Lightspeed - I have little experience with this particular tool myself (customers generally object to paying for an ORM when there are good free alternatives) but it is highly regarded.

Answer 2

I don't have any experience with OODBMSes, but my experience with NHibernate + MS SQL Server has been very positive in terms of enforcing and cascading changes down one-to-many, many-to-one and many-to-many relationships.

What OODBMS tool are you using? It might be possible that an OODBMS -> RDBMS migration tool exists, but I'm not aware of any.