In the .NET world, the Object-Relational Mapping space continues to be among the most active areas. For some developers, ADO.NET is good enough to deal with their data needs. For some other developers, who have embraced object technology in full, Object-Relational Mapping (ORM) software is needed to successfully field their enterprise systems.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Object Relational Mapping has been gaining attention as a way of helping programmers to organize their objects in such a way that can be better integrated into new programs. A variety of ORMs have emerged over the years, but questions have emerged as to whether they ultimately save time, or require more effort in the long run.
Microsoft edged into the area in the not too distant past with its ObjectSpaces ORM software. But the company suspended its ObjectSpaces effort. Like some other aspects of the Longhorn operating system -- which became Vista client as a product and then Longhorn Server still in development -- it was a feature that was removed in order to ship the product. This left an opening for open-source software advocates and third-party data access software vendors ready to fill the void.
The void may be short lived – several influential Microsoft development gurus got behind an effort to create LINQ as part of Orcas, the next version of Visual Studio and its C# and Visual Basic languages. LINQ, short for Language Integrated Query, is a set of Microsoft .NET Framework alterations that are intended to ease the developer's role in data query building.ORMs to the fore
A number of ORMs have come to the fore since Microsoft began to ratchet back its ObjectSpaces effort in 2004. A very influential solution, coming out of the Java open-source Hibernate project, has been NHibernate. It provides persistent classes for object-oriented development. The NHibernate developers attempted to create APIs very similar to Hibernate, which has proved a popular approach.
Along with NHibernate (which is supported through Hibernate.org), data-oriented developer solutions for handling objects come from companies including Alachisoft, EntitySpaces.NET, Progress Software, RogueWave, SoftwareTree, Wilson ORMapper, X-tensive and others.
Last month, NHibernate 1.0.4 was released through Hibernate.org. NHibernate relies on third-party code generation software to generate mapping files from source code.
"I can't say NHibernate is simpler to use initially. In fact, I think it's exactly the opposite," noted Sergey Koshcheyev, lead developer on NHibernate, "because NHibernate is based on certain concepts and principles related to session management that may be difficult to grasp initially. In the long term, however, this pays off since the principles encourage doing the right thing."
Another thing that makes NHibernate useful in the long term are hooks that NHibernate provides for plugging into its functionality. "Of course, if you listen to users, the existing hooks are never enough, and more and more are being added into every new version of NHibernate," said Koshcheyev. "These hooks include allowing fall back to SQL if NHibernate functionality is not enough."
Talking 'bout code generation
Code generation has never been without controversy. In the ORM space, individuals have suggested that coupling these tools to ORMs can quickly create solutions that then become time-consuming to manage.
Another ORM, Genome, does not generate any code that needs to be managed, so that the process can be more sustainable.
Christian Hassa, a managing partner at TechTalk, which makes the Genome ORM, said, "ORM tools entail an initial cost when you introduce them in a project, as you need to familiarize yourself with the API and overcome a more or less steep learning curve. This cost however pays off when you enjoy the benefits of ORM later.
"The myth that ORM generates quick wins in the beginning that you pay dearly for at a later stage most likely arises from tools that quickly generate lots of code, seemingly delivering a quick, functioning solution," said Hassa. "Upon first inspection, you seem to have saved time and effort. Later on, when poring over that generated code that has become part of your managed code assets, you'll realize that any generated code also needs to be maintained - don't even think about re-generating it.
"Those initial quick wins by no means justify the substantial costs incurred later, when attempting to maintain the solution." she said. "Solutions that give you the impression of solving everything 'automagically' fall apart when you need to deal with the nasty details."
Falling back to SQL
Many experts agree that a good architecture is significantly more important that a fancy new storage bin. It is kind of like asking if giving a carpenter a supply organizer will make a better carpenter. If the carpenter already has the discipline to organize supplies to support the process of building a house, it will make the job easier. Otherwise it is likely to become one more source of clutter in a hectic process.
Koshcheyev said, "Understand that ORM is not a silver bullet. Don't be afraid to fall back to SQL if you hit a wall. Every OR mapper has its quirks and limitations, this seems to be the nature of this type of software."
What should one look for in an ORM? The ability to appear when it is needed and disappear when its not needed seems to be one of them.
"From an architectural perspective, I do not want an ORM to put a heavy thumbprint on my data base or object model," said Ben Day, principal at Benjamin Day Consulting."If Object Relational Mapping does not work, I want to be able to pull it out without scrubbing the whole design. Sometimes ADO.NET and Stored Procedures will be easier," said Day. "I want the ORM to help me out when I need it and not get in my way when I don't need it. I think NHibernate does that pretty well."
One of the challenges with ORMs is the lack of standards, which may be resolved by Microsoft's de facto LINQ standard, expected to set a common method for expressing queries for all ORMs. So LINQ may not actually threaten the emerging ORM tool market.
Tech Talks's Hassa said, "LINQ is a fact for the future – the question is only when, whether it will be launched proper at the end of 2007 or if we need to wait until 2008. ORMs should provide a good migration story to LINQ and protect your project investments for the time when LINQ has been released."