Comments on: Does object persistence complicate architectures with existing data models? http://www.brianlegros.com/blog/2007/10/07/does-object-persistence-complicate-archictetures-with-existing-data-models/ eat, program, and be merry Tue, 23 Feb 2010 05:56:46 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Brian LeGros http://www.brianlegros.com/blog/2007/10/07/does-object-persistence-complicate-archictetures-with-existing-data-models/comment-page-1/#comment-193 Brian LeGros Thu, 11 Oct 2007 13:36:23 +0000 http://www.brianlegros.com/blog/2007/10/07/does-object-persistence-complicate-archictetures-with-existing-data-models/#comment-193 @Brian - Whoever said that is an idiot ... :'( @Brian – Whoever said that is an idiot … :’(

]]> By: BrianShoeman http://www.brianlegros.com/blog/2007/10/07/does-object-persistence-complicate-archictetures-with-existing-data-models/comment-page-1/#comment-192 BrianShoeman Thu, 11 Oct 2007 13:23:15 +0000 http://www.brianlegros.com/blog/2007/10/07/does-object-persistence-complicate-archictetures-with-existing-data-models/#comment-192 As a great (and strangely self-loathing) developer once told me, "It's just another tool in your toolbox." As a great (and strangely self-loathing) developer once told me, “It’s just another tool in your toolbox.”

]]> By: Brian LeGros http://www.brianlegros.com/blog/2007/10/07/does-object-persistence-complicate-archictetures-with-existing-data-models/comment-page-1/#comment-188 Brian LeGros Thu, 11 Oct 2007 00:36:00 +0000 http://www.brianlegros.com/blog/2007/10/07/does-object-persistence-complicate-archictetures-with-existing-data-models/#comment-188 @Max - Great example with Hibernate. I haven't worked with Hibernate yet (except in the context of Grails), but I really like iBatis, especially for the things we do at CFI. Thanks for the great comment. @Max – Great example with Hibernate. I haven’t worked with Hibernate yet (except in the context of Grails), but I really like iBatis, especially for the things we do at CFI. Thanks for the great comment.

]]> By: Maxim Porges http://www.brianlegros.com/blog/2007/10/07/does-object-persistence-complicate-archictetures-with-existing-data-models/comment-page-1/#comment-184 Maxim Porges Wed, 10 Oct 2007 04:27:04 +0000 http://www.brianlegros.com/blog/2007/10/07/does-object-persistence-complicate-archictetures-with-existing-data-models/#comment-184 Great post. With regard to ORM, I've seen several things happen in our environment: (1) people try to use it when it's not appropriate to do so, and then get upset with it as if it's the tool's fault, and/or (2) people spend much longer fighting with ORM in bad use cases than they should when they could just reach for a more appropriate solution. The one project I personally used Hibernate for involved a fresh data model and mapped beautifully to the solution. All the benefits of ORM were realized, with the persistence tier being managed 100% by the framework. There were no problems encountered that took more than a quick perusal of the manual or forums to resolve, and performance tuning the HQL was easy and behaved as expected. In retrospect, Hibernate gave us the power to really break up the table structure in to a way that I don't think we would have if we had coded the persistence by hand. We used <a href="http://martinfowler.com/eaaCatalog/classTableInheritance.html" rel="nofollow">Class Table Inheritance</a>, which is downright difficult to understand just by looking at the tables unless you have a deep understanding of the mapping relationships. If I had to do it again I would go with <a href="http://martinfowler.com/eaaCatalog/singleTableInheritance.html" rel="nofollow">Single Table Inheritance</a>, since it feels closer to a natural relational model, is easy to understand just by looking at the table structure, and makes writing queries outside of the ORM framework much simpler. You end up with sparsely populated tables, but I think that's a fair trade off. iBatis is a nice bridge between full-on ORM and rolling your own persistence. It still provides value by acting as an object factory, and can provide nice mappings between mismatched relational and object models since you are closer to the metal. It's much easier to map iBatis around inconsistencies than it is to try to get Hibernate to do that for you. Your last point is really poignant, which is that you don't have to use ORM (or feel dirty if you don't). If the overhead of using a tool is higher than not using it, it's not a tool IMO; it's a millstone around your neck. Since it's so easy to mix and match data persistence strategies in whatever DAO or gateway pattern you are implementing, there's really no excuse to fight with a framework when you can just wrangle the data by hand like we did back in the old days before ORM existed. Great post.

With regard to ORM, I’ve seen several things happen in our environment: (1) people try to use it when it’s not appropriate to do so, and then get upset with it as if it’s the tool’s fault, and/or (2) people spend much longer fighting with ORM in bad use cases than they should when they could just reach for a more appropriate solution.

The one project I personally used Hibernate for involved a fresh data model and mapped beautifully to the solution. All the benefits of ORM were realized, with the persistence tier being managed 100% by the framework. There were no problems encountered that took more than a quick perusal of the manual or forums to resolve, and performance tuning the HQL was easy and behaved as expected.

In retrospect, Hibernate gave us the power to really break up the table structure in to a way that I don’t think we would have if we had coded the persistence by hand. We used Class Table Inheritance, which is downright difficult to understand just by looking at the tables unless you have a deep understanding of the mapping relationships. If I had to do it again I would go with Single Table Inheritance, since it feels closer to a natural relational model, is easy to understand just by looking at the table structure, and makes writing queries outside of the ORM framework much simpler. You end up with sparsely populated tables, but I think that’s a fair trade off.

iBatis is a nice bridge between full-on ORM and rolling your own persistence. It still provides value by acting as an object factory, and can provide nice mappings between mismatched relational and object models since you are closer to the metal. It’s much easier to map iBatis around inconsistencies than it is to try to get Hibernate to do that for you.

Your last point is really poignant, which is that you don’t have to use ORM (or feel dirty if you don’t). If the overhead of using a tool is higher than not using it, it’s not a tool IMO; it’s a millstone around your neck. Since it’s so easy to mix and match data persistence strategies in whatever DAO or gateway pattern you are implementing, there’s really no excuse to fight with a framework when you can just wrangle the data by hand like we did back in the old days before ORM existed.

]]>