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) on 2004.08.10 23:12 (#33296) Journal

      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 Tomcat, and the code generation library being used is pretty common in Java open source projects these days.

      I can't see complaining about its dependencies being fair, considering how many Class::DBI has. And it's hard for me to imagine a perl interface for declaring all of that metadata that would be any easier to read than the XML config. Plus it's neat to write classes without any database awareness in them at all and then magically persist them by writing this separate config.

      All I'm saying is, don't dismiss it as needlessly complex so quickly. Hibernate is only tricky in the places where the underlying problem it's trying to solve is tricky. It has some good ideas and has really had a big impact on how object persistence is done in Java.

      Reply to This

      Parent

      • Re:overstating it a bit? (Score:2)

        by ziggy (25)

        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 tha