Posted by Gerhard Stephan on 13th October 2006
Reason to start the ObjectMapper .NET project
In 2003 I had the opportunity to work in a Java project which used Hibernate 1.25 and later 2.0. I was responsible for developing the business logic and parts of the data access layer.
The application had been developed following the good old MVC model. Whereas the presentation framework was using Struts and Tomcat, the business logic has been developed using Java Beans and JBoss. Oracle has been used as the database management system. Note that Tomcat and JBoss had been running on different machines to get better scalability.
The idea behind the then young Hibernate Framework fascinated me. But actually using it quickly showed the pitfalls.
This is a list of my concerns:
• It took quite some work to get the first database access up and running. It started with migrating the class model to the HBM-XML file and then to the database model. Because everything was maintained separately, keeping these things consistent took quite some effort and was a constant source of errors. Even the use of XDoclet could not significantly simplify this.
• The transport of entity objects from business logic (BL) to user interface (UI) and back required these entities to be serializable (because of the machine hop). Saving those objects a second time, Hibernate tried to insert the object again, thus producing duplicates or constraint violations.
After an extensive search we realized that Hibernate used the object reference to identify whether the object had to be inserted or updated. However those references had changed due to the serialization..
• In order to limit the amount of database calls, we decided early on to use the propagated Lazy Loading functionality. Development on a single machine worked fine, but after distributing business logic (JBoss), oracle database, and user interface (Tomcat) on separate machines nothing worked anymore. Why?
Because of the Lazy Loading mechanism the UI tried to connect to the database to load missing entities. This inevitably failed because the UI did not (and should not) have access to any database for security reasons.
• After dismissing Lazy Loading, Hibernate only offered the possibility to load entities in the whole (i.e. including all object dependencies). Because we didn’t want to load the complete database in memory, we had to flatten our object model. Therefore we removed aggregated objects and stored the foreign keys instead. This lead O/R Mapping with Hibernate ad absurdum.
I’m sure that Hibernate has evolved since that time. But at that time those issues formed my impression of Hibernate and created the wish to develop a new O/R Mapping Framework that prevents the pitfalls mentioned above.
However since the java project I was involved in depended heavily on Hibernate, it would have cost too much effort to replace it with another O/R Mapping Framework. At the same time I got interested in C# .NET. Consequently I decided to write my new O/R Mapping Framework for C# .NET.
This was the beginning of the ObjectMapper .NET (or rather DatabaseMapper, which was its name at that time). The development started in the middle of 2003.
The development 2003 to 2005
In the years 2003 to 2005 the DatabaseMapper had been a private project in which I tried to do everything right, which was not always possible. But over time and after some twists and turns the result was presentable.
The following demands have been important for me and I still check the ObjectMapper .NET for this points.
1. The O/R Mapping Framework should simplify and speed up the development, so that first results can be shown rather quickly. That includes the support of the MDA paradigm.
2. The O/R Mapping Framework should be usable with stand alone applications just as well as with distributed applications under high load.
3. The O/R Mapping Framework should work transparently to the user. The developer should not have to care too much about database relations and foreign keys. The OO paradigm should be supported as best as possible.
The first versions of the DatabaseMapper have been used professionally in the time recording tool TimePunch v1.82.
The breakthrough 2005
In 2005 I had the chance to join a project at Commerzbank AG Frankfurt. A new CRM System had to be developed to displace the old CRM System.
The decision to use object based data access rather than ADO.NET datasets was already made. Consequently the question came up which O/R Mapping Framework to use.
After some discussions about the pros and cons of the respective products, performance tests, etc., the project leader could be convinced to use the DatabaseMapper as the O/R Mapping Framework.
I should emphasise that this has not been my decision alone. Within the team the DatabaseMapper, had been compared with the quasi standard NHibernate. The crucial factors for choosing the DatabaseMapper in favour of NHibernate have been:
1. The already described problem of NHibernate to directly access the database from the UI, without using the business logic.
2. The fact that NHibernate forces the developer to use its provided collection classes rather than allowing the usage of self defined container implementations.
3. Some other disadvantegous features, e.g. the partly redundant, but in all cases separated (and therefore error prone and maintenance intensive) configuration of NHibernate.
All in all these were the very issues that triggered the development of the DatabaseMapper in the first place.
Of course, this was a big step forward, because the DatabaseMapper now had to prove its qualities in a major project in one of the biggest German banks.
Up to this day it has been one big success story. The project ISIS is already productive and version 2.0 will be released by the end of 2006. And until today it benefits from the O/R Mapping Framework I developed. Currently the project uses more than 200 tables and several gigabytes of data.
The first “official” Release
Since the first attempts had worked very well and the DatabaseMapper became even more stable and at the same time supported more features in later versions, I decided to publish the DatabaseMapper under the new name “ObjectMapper .NET” as an open source project.
The decision for an open source project was driven by the wish of getting public attention and a broader user base as fast as possible.
The 1st Jan 2006 became the birthday of the ObjectMapper .NET. At this day I announced the project in SourceForge under the GPL License and published the first “official” release.
I published the ObjectMapper .NET under the GPL License, hoping that this is the best balance between the wish to make the O/R Mapping Framework accessible to a huge community and at the same time earning money by selling commercial licenses. Therefore the ObjectMapper .NET will be marketed with dual license.
Right now I would like to thank all people who supported the development of the ObjectMapper .NET in one way or the other. Special mention should be given to those two guys:
Karl Reitschuster: As an accounted expert for Oracle he helped me to optimize the output of the OraclePersister used by the ObjectMapper .NET. Furthermore Karl Reitschuster developed a PL SQL AddOn that works as a garbage collector. E.g. The AddOn handles deferred deletions if the object is still referenced by other entities. For more information on this topic please contact Karl Reitschuster directly.
Alexander Jung: With his hints and insights regarding performance optimization, Alexander Jung played his part in making the ObjectMapper .NET outperform other O/R Mapping Frameworks. Furthermore he reviewed the web pages for spelling and grammar and helped putting the finishing touches to the ObjectMapper .NET
A look into the future
Predicting what will happen to the ObjectMapper .NET isn’t that easy. The development has been/will be largely driven by the demands and feedback of the people using the ObjectMapper .NET within their projects.
The big challenge will be the integration of LINQ into the ObjectMapper .NET. It is not conceivable yet whether the ObjectMapper .NET should work as a data source for LINQ or whether it should use LINQ as a query source.
Furthermore the support of additional data sources beside Oracle, SQL Server, or Microsoft Access Database rises up on the wish list. The support of MySQL is definitely planned for the nearer future.
But this is for sure: The ObjectMapper .NET will stick to its principles to simplify the work of the developers.