use Perl

• overstating it a bit? (Score:1)

  by perrin (4270)

  Hibernate is more complex than Class::DBI, but it's not hard to use. To your specific complaints, Hibernate doesn't need Tomcat, although Tomcat is a common place to use it. It uses code generation, but so Class::DBI. In both cases, the code generation is done at run-time. It does use XML config files, and I kind of like them. Take a look at this one from the quickstart chapter:

  <?xml version="1.0"?>
  <!DOCTYPE hibernate-mapping
      PUBLIC "-//Hibernate/Hibernate Mapping DTD//EN"
   
  • Re:overstating it a bit? (Score:2)

    by ziggy (25)

    Hibernate doesn't need Tomcat, although Tomcat is a common place to use it.

    Whatever. I really don't care if Hibernate or Hibernate's docs are making my skin crawl. I've been programming long enough to know that I'm looking for a thin shim that converts application-level concepts into database actions, and that I want that as a single aspect in my codebase. If the Hibernate folks are telling me that I need a full-bore seven layer burrito [pablotron.org] to use their code, I'd rather write my own CDBI-inspired abstr
    • Re:overstating it a bit? (Score:1)

      by perrin (4270)

      Mapping a data model with any complexity between objects and a database is just not that simple a problem. Hibernate is pretty easy to use. It might look complex to you if you are not already familiar with current Java concepts, in the same way that Class::DBI leaves many Perl newbies scratching their heads. There is a basic assumption that you've already written some Java apps with databases and objects and thus are familiar with the terms and libraries. I wouldn't hire a Java coder who didn't know Tom
      • Re:overstating it a bit? (Score:2)

        by ziggy (25) on 2004.08.10 23:59 (#33297) Journal

        I'm still not swayed. Let's just call this a bikeshed and move on.

        I've written about three database abstraction frameworks in the last two years, none of which have had a dependency aside from DBI / database drivers. So it is possible, even if it doesn't scale up to handle every degenerate schema on the planet.

        That's fine. What I'm looking for is probably outside the scope of what Hibernate is trying to deliver (or, best case, what the Hibernate docs have chosen to focus on). I can live with that. I've found that ~80% of the benefit is not from purging SQL code from an application and replacing it with an ORM framework. The primary benefit comes from programming in an aspect-like manner, separating the generic database code from the schema management, and separating schema management from the rest of the application. With that big a win, I haven't found the need use ORM frameworks.

        But that's just me. I could be wrong here.

        Reply to This

        Parent