tag:blogger.com,1999:blog-22587889.post50891457779353362..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: Are ORMs really a thing of the past ?Anonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-22587889.post-89978653808354548892010-03-04T12:23:05.695+05:302010-03-04T12:23:05.695+05:30I view SQueryl as more of a small scale option alt...I view SQueryl as more of a small scale option although I'd still write a domain model that is separate from the persistent model with that tool. <br /><br />The .Net world offers the <a href="http://www.infoq.com/news/2009/08/nh_linq1" rel="nofollow">best of both worlds</a> with the NHibernate guys supplying a Linq provider. The Linq generates criteria API calls rather than SQL.Unknownhttps://www.blogger.com/profile/11223865313059961359noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-61392590642666817632010-03-03T11:17:01.493+05:302010-03-03T11:17:01.493+05:30I have looked at SQueryl. Then there is ScalaQuery...I have looked at SQueryl. Then there is ScalaQuery as well and quite a few other frameworks inspired by LINQ. All of them do a nice job of providing type safe queries on the domain objects. This way you save a lot from writing SQLs. But my main concern is that this process can quickly go out of bounds in a large project where you may have thousands of tables. Besides hiding SQLs, an ORM also does this job of virtualizing the data layer. This means you can scale up your data layer as transparently using products like Terracotta, Coherence or Gigaspaces. I like the elegance of LINQ inspired frameworks, but still skeptical about their usage in a typical enterprise application which needs high scalability.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-25988141152365165882010-03-03T11:05:16.216+05:302010-03-03T11:05:16.216+05:30I don't think ORMs are a thing of the past but...I don't think ORMs are a thing of the past but I also don't think they are a one size fits all option.<br /><br />I was wondering if you've had a chance to check out <a href="http://squeryl.org/" rel="nofollow">Squeryl </a>? This is a LINQ style DSL for Scala. Eg:<br /><br />def songsInPlaylistOrder =<br /> from(playlistElements, songs)((ple, s) =><br /> where(ple.playlistId === id <br /> and ple.songId === s.id)<br /> select(s)<br /> orderBy(ple.songNumber asc)<br /> )<br /><br />This is translated to SQL and executed for you. If you need to refactor (assuming someone will develop adequate refactoring tools for Scala) nothing is missed because there are no hbms to worry about.Unknownhttps://www.blogger.com/profile/11223865313059961359noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-85426484267307144132009-10-29T16:39:08.650+05:302009-10-29T16:39:08.650+05:30Session-less Approach
----------------------
For t...Session-less Approach<br />----------------------<br />For those wanting a "session-less" approach you can also check out Ebean ORM to see if it is more of your liking.<br /><br />http://www.avaje.org<br /><br />This means you don't need to worry about <br />- LazyInitialisationException <br />- management of session objects (Hibernate session/ JPA EntityManager).<br />- merge/persist/flush replaced with save<br /><br />Sorry for the blatent plug but if you are looking for a simpler/session less approach it would be worth a look :)<br /><br />Cheers, Rob.Robhttps://www.blogger.com/profile/15681828713730105495noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-26880027599664819432009-10-19T21:58:11.988+05:302009-10-19T21:58:11.988+05:30@Anonymous (of the last comment)
You resonate pret...@Anonymous (of the last comment)<br />You resonate pretty much what I wanted to say. It's true that ORMs like Hibernate are not without the warts. At the same time they offer a tonne of benefits too. My suggestion will be :<br />1. to use what good they offer (and they really offer a lot)<br />2. avoid the sucky features<br />3. use your judgement to selectively apply the ones that are debatable.<br /><br />If you do not want to use the persistence context or automated session management, use the stateless session interface, where you use your ORM to marshal / unmarshal data out of your RDBMS and get stuff in the form of detached objects. Hibernate offers this .. check out http://docs.jboss.org/hibernate/core/3.3/reference/en/html/batch.html#batch-statelesssession ..Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-7537145363009419492009-10-19T21:13:33.140+05:302009-10-19T21:13:33.140+05:30I worked on a complete rewrite of a system and the...I worked on a complete rewrite of a system and the Lead Developer did not use an ORM. We basically wrote our own, and it was a total mess and a waste of time. We spent most of our time debugging our data access layer and never made meaningful progress on the true functional requirements. After a year of hell, the Lead was fired and we threw the code away and started over with an ORM. What a relief! Not having to spend a lot of time dealing with the data access layer freed us up to focus on the functional requirements which makes happy clients which makes happy managers which makes happy developers. <br />Somehow I ended up on a team of developers that thought 3rd party tools are for wimps, and they could write everything themselves. What a bunch of arrogant fools, and what a waste of time. If we had all the time in the world, maybe we could write a better tool, but I doubt it. I freely admit that developers who create tools like Hibernate are smarter than me. Why would I waste any time trying to reinvent the wheel? It may not be perfect, but it's better than anything I could create myself. As for the arrogant fools who liked to create their own tools instead of just finding one already built? They were all fired at various times for consistently not finishing projects.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-16530487652928784092009-10-19T19:24:47.616+05:302009-10-19T19:24:47.616+05:30Rails doesnt use straight SQL, so there is no need...Rails doesnt use straight SQL, so there is no need to move away from ORMs. Just wait and see what the Rails guys do.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-88526939276290618812009-10-19T19:16:39.743+05:302009-10-19T19:16:39.743+05:30Maybe the real solution is some kind of "exte...Maybe the real solution is some kind of "extended ddl" where one could specify validations/constraints/other business logic" more easily. <br />Like Hibernate, but without the "object mapping" part (why should one try to map relational data to objects?). Like "stored procedures", but functional instead of procedural (though i like spaghetti with cheese).<br /><br />(just an idea)Unknownhttps://www.blogger.com/profile/14062673088358461922noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-76388689052284935192009-10-19T17:14:59.904+05:302009-10-19T17:14:59.904+05:30I can understand decoupling your domain model from...I can understand decoupling your domain model from the database in that the domain objects should be simple POJOs. That is where something like JdbcTemplate really shines (similar to using iBatis).<br /><br />In this modern era of polyglot, how come we don't recognize that SQL is a language of its own. When tuning queries, it seems easier to enlist our team's database engineer to help me out by showing him queries, rather than bringing him up to speed on XYZ-QL.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-60743629876391752722009-10-19T11:53:43.569+05:302009-10-19T11:53:43.569+05:30Just put everything in stored procs, then your jav...Just put everything in stored procs, then your java code is completely shielded from the database structure. I've used this approach on a number of projects, and it has worked well. Simple and easy to maintain. This is in stark contrast to the ORM based projects I've worked on where no one on the project truly understood what was going on with all of the complex mappings, cachings, cryptic errors, etc. I can show any who knows SQL how to do virtually anything needed in a few hours with stored procs. ORM adds much more complexity...and I often see lazy loading all over the place causing horrible performance.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-35622679287555230162009-10-18T19:52:47.628+05:302009-10-18T19:52:47.628+05:30I'm not sure with Stephen means that ORMs cann...I'm not sure with Stephen means that ORMs cannot help when refactoring a database; they help a hell of a lot more than strings containing SQL all over the place would; it's trivial to write an integration test to load up all your mapped beans and try to access one. If your mappings and database are inconsistent, you will know immediately what is the problem and where.<br /><br>Having seen many codebases NOT using an ORM, I have to say they were all a big, huge, mess. ORM makes the code cleaner (or can help). And clean code can be refactored, maintained and optimized a lot better than a big mess of SQL statements everywhere.Davehttp://www.naildrivin5.com/blognoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-58711459988455240042009-10-18T15:14:39.569+05:302009-10-18T15:14:39.569+05:30ORM is nothing more than an alternate marshalling ...ORM is nothing more than an alternate marshalling scheme. To add layers upon layers of marselling has never made sense. That said db calls are tied to the network and is the case with all technologies that rely on aslow under pinnings caching will be essential. The best way to make an application cache resistant is to scatter the calls throughout your application. At least ORM normalize execution paths which makes it easier to add caching.<br /><br />That said for the moment, applications are going to need to rely on something other than RDB technologies if they are going to scale. Technologies such as memcached look very interesting in that it is a very simple technology that is highly scalable <br /><br />KirkAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-61391446421594434272009-10-18T01:55:46.797+05:302009-10-18T01:55:46.797+05:30Lazy Initialization is not a feature/side-effect o...Lazy Initialization is not a feature/side-effect of ORMs, they can be present in your DSLs as well.<br /><br />ORMs seems like a hindrance at the start of the project or when there are less "objects".<br /><br />I think they are well suited for Object-Oriented minded teams. But now, as we are exploring different areas, paradigms, we tend to move away from ORMs and that's natural for these kinds of projects.Monis Iqbalhttps://www.blogger.com/profile/02705136015120934248noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-11496241003395601942009-10-18T01:38:36.124+05:302009-10-18T01:38:36.124+05:30I am starting to learn that Hibernate requires mor...I am starting to learn that Hibernate requires more understanding and time than most people want to give it, but with that understanding, it can really work for you. I was talking to a user yesterday who asserts that QueryCaching is bad for him. I listened, checkpointed with someone who knew query caching very well, and found out that it will indeed work for this user if used properly.<br /><br />I see that since Terracotta stopped fighting Hibernate and embraced it in the market and now that we build products for Hibernate users, my understanding of the technology has grown. Our ability to serve the needs of higher performance while staying within the confines of the Hibernate world have vastly improved over the last year. <br /><br />Yes Hibernate has a few problems but I see the path fwd as contributing fixes and helping and not trying to invent yet another way to do what is inevitable, marshaling data to and from an RDBMS.<br /><br />--AriUnknownhttps://www.blogger.com/profile/08864794870737829029noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-41259616596676364172009-10-18T01:21:01.167+05:302009-10-18T01:21:01.167+05:30"Have a look at how grids like Terracotta can..."Have a look at how grids like Terracotta can use distributed caches like EhCache to scale out your data layer seamlessly."<br /><br />We use TC and it does scale out our data without Hibernate.<br /><br />Cheers<br />StephanStephan.Schmidthttps://www.blogger.com/profile/03845125686370893937noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-42976664860145490982009-10-18T01:06:04.501+05:302009-10-18T01:06:04.501+05:30You can also use refactoring aware SQL dsls like s...You can also use refactoring aware SQL dsls like squill, jequel, empiredb. <br /><br />Regarding those _big_ domain models. In DDD terms they are broken anyway as there are no modules or bounded contexts that address the relevant part of the domain model at once.<br /><br />When talking to BigDaveThomas at JAOO he also stressed that most solutions today are just simple CRUD systems that are bloated with ORM. Just mapping the tables to a screen is often a simple case of generic SQL and you're done :)<br /><br />Michael<br />MichaelUnknownhttps://www.blogger.com/profile/01655903344516494861noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-12325856345593667562009-10-18T00:30:50.408+05:302009-10-18T00:30:50.408+05:30Some comments:
"[...] littered with SQL that...Some comments:<br /><br />"[...] littered with SQL that's impossible to refactor when my schema changes."<br /><br />Never saw a ORM (like Hibernate) help when changing the database. And on the contrary: I haven't seen schema changes in large databases, because too many systems (reporting, accounting) depend on a schema. Your domain model will change much more likely, and when the gap between your domain classes and your db is too large, your ORM will break. This often prevents refactoring of domain classes.<br /><br />"If you are not designing an ActiveRecord based model, it's of paramount importance that you keep your domain model decoupled from the persistent model."<br /><br />As said above, ORMs do not decouple your domain classes from the database, but instead nail your domain classes to your database schema.<br /><br />Ever tried splitting domain classes that are in one table? Everything beside renaming classes and attributes is out of the window if you use an ORM (just my experience, YMMV).<br /><br />Cheers <br />Stephan<br />http://www.codemonkeyism.comStephan.Schmidthttps://www.blogger.com/profile/03845125686370893937noreply@blogger.com