Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Hibernate and iBatis co-existing

AppFuse is in an interesting state right now. In order for me to easily switch to using iBatis for the DAO layer, I left all the Hibernate stuff intact and just added iBatis classes and JARs. The next step is to extract the iBatis stuff into a separate CVS module and write a build.xml file to replace the Hibernate implementation with iBatis.

The one thing that will suck, in the iBatis version, is that the database can't be dynamically created from POJOs. However, if you're going to use the iBatis implementation, its likely that the database (or SQL) already exists. The reason I'm writing this post is because right now, in CVS, you can change the dao.type property to "ibatis" or "hibernate" when building and Voila! - that's the implementation you'll get. I see no reason why any project would ever want to have both implementations (maintenance would be a nightmare), so that's why I'm extracting the iBatis stuff in the next few days.

Posted in Java at Feb 10 2004, 04:20:47 PM MST 4 Comments
Comments:

Well, I think there is a huge value in keeping them together. Hibernate will cover most of the trasactional part of the application, where you are going from id to id. When it comes to reporting or heavy-load quering then you may not be happy with SQL that hibernate generates or may want to tune it, iBatis gives you complete control over SQL to do that. I think, ideal situation would be 80% stuff covered with Hibernate for the rest of 20% use iBatis. Prashant Rane

Posted by Prashant Rane on February 11, 2004 at 01:11 AM MST #

Prashant, I don't know iBates, but I DO know that Hibernate gives you complete control over the SQL, should you want that. Also, the new Hibernate Criteria functionality that is added to (2.0/2.1) is starting to look promising. In any case, using two database services next two each seems quite heavy. Also in terms of learning curve, etc.

Posted by Jaap on February 11, 2004 at 12:11 PM MST #

Could you elaborate when to use iBatis and when to use Hibernate? I searched google and found no clue. Thanks! CT

Posted by Unknown on February 11, 2004 at 01:25 PM MST #

I've used Hibernate on several projects and iBatis on one. You can read about why we used iBatis from a post in October. For me, if you're going to write a webapp to talk to an existing database, iBatis might be easier - especially if the SQL is already written (as was the case on my project). If you're creating the database from scratch, Hibernate is the best choice IMO. Also, if you have developers that would rather do SQL, or you have expert DBAs on staff - then iBatis might be easier to learn/use.

Last night, I was successfully able to rip out iBatis from AppFuse's core and put it into a contrib directory. I added an "install" and an "uninstall" target (to build.xml in contrib/ibatis) that will install/uninstall iBatis - leaving the Hibernate support intact. Today I'll create another target, "uninstall-hibernate" that will allow the user to choose a iBatis-only solution. That way, if the user runs "install" without running "uninstall-hibernate" they can have both implementations to look at and use.

Posted by Matt Raible on February 11, 2004 at 01:48 PM MST #

Post a Comment:
  • HTML Syntax: Allowed