On Sun, Oct 24, 2010 at 10:53 PM, Rob <[email protected]> wrote: > If not are there other ways to take advantage (if there is an > advantage) of Hibernate? >
What follows is my own personal opinion and shouldn't be construed to indicate anything even remotely concrete about the direction ORM may or may not take in OpenBD. Now with the legalese out of the way ... ;-) ORM is a pretty hefty double-edged sword IMO, and I'm conflicted on specifically what I'd like to see for ORM in OpenBD for numerous reasons: 1. Personally I don't think ORM was implemented well in CF 9. The syntax is horrendously and unnecessarily verbose, so on a technical level I have issues with making ORM in OpenBD syntax compatible with CF 9 because I don't think it's the best way to do things. I'd like to see a better solution with maybe a CF 9 syntax compatibility layer on top. For example, the persistence in OpenBD for GAE isn't feature complete yet, but it works really well and is dead simple to use, so maybe going that route on the non-GAE edition would make sense. 2. I agree with Ted Neward's assessment that ORM is the Vietnam of computer science. http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx Most pertinent quote: "It represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy." 3. Kind of related to point 2 above, ORM is deceptively simple, but if you get into anything beyond the most trivial of use cases, you're having to worry about what your ORM layer is doing which can eat into the time you're supposedly saving by using ORM, and in addition problems with ORM can be pretty complex to troubleshoot. There was a session at SpringOne last week on this very topic, and doing things in what seems like a perfectly natural and "right" way can really bite you if you don't know what's going on behind the scenes and plan for it. If you have one-to-many and many-to-many relationships, for example, you immediately need to understand exactly what Hibernate is doing, model correctly to avoid performance problems, and in many cases handle things more manually (meaning have a domain class for the *relationship* between objects and handle cascading deletes yourself) than you'd think you'd have to. 4. NoSQL (which people have started saying stands for "not only SQL" as opposed to "no SQL") databases are picking up a lot of steam and are changing the way people look at ORM. I've been doing some work with CouchDB and if your application's data is a good match for this way of dealing with data, then ORM is completely irrelevant. If your data doesn't fit well with a document-based or key-value database, then chances are you're dealing with things like reporting on columnar data, which ORM would be bad for anyway. In most real-world cases you wind up with a combination of the two database types, and of course then you get the best of both worlds, but chances are in those cases you'd be better off writing SQL to handle things like reporting anyway. 5. By using ORM you're paying a run-time performance hit to ostensibly save yourself development time. I realize a lot of this is mitigated by using second-level caching either in the ORM framework itself or by using something like memcached for your second-level caching, but then you're introducing another layer of complexity to handle the performance issues that can be associated with ORM. And caching itself can be a complex topic--lots of people use the query cache in Hibernate rather blindly, but given the work Hibernate has to do to manage the cache, you have to really analyze things to see if you're actually better off caching or if it's more work for Hibernate to manage that than it would be to have it just return the data. All this being said, and despite how it may sound, I don't hate ORM. What bothers me is the "now that I have ORM I can kiss SQL goodbye forever" school of thought that plagues some developers. ORM is a tool, like all tools it has its pros and cons, you have to learn the tool very well to use it effectively, and it's not the silver bullet many would like to make it out to be. -- Matthew Woodward [email protected] http://blog.mattwoodward.com identi.ca / Twitter: @mpwoodward Please do not send me proprietary file formats such as Word, PowerPoint, etc. as attachments. http://www.gnu.org/philosophy/no-word-attachments.html -- Open BlueDragon Public Mailing List http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon official manual: http://www.openbluedragon.org/manual/ Ready2Run CFML http://www.openbluedragon.org/openbdjam/ mailing list - http://groups.google.com/group/openbd?hl=en
