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's AdminApp - a demo of WW2 and Hibernate

After looking at Hibernate's AdminApp, as well as other WW2 apps - I've noticed something. WW2 developers don't seem to give a rats ass about referencing their POJOs in their Actions, or using Hibernate directly in their actions. At first glance, I think to myself, "boy that sure makes things easier." But then again - doesn't that tightly couple your web layer to your persistence layer?

I can understand the POJO reference in Actions - I'm about to give up on doing a parent/child relationship with Hibernate where the children are converted to ActionForms and then converted back (Hibernate loves to tell me "a different object with the same identifier value was already associated with the session: 1").

It would be SO much easier (with this particular problem) if I could just toss up POJOs to my view. The thought of importing "persistence.User" into my Action makes me cringe though. I don't know why, it just does. I need to get out of this patterns mindset I've been in for the last couple of years and get back to what really matters - simple, easy to learn, and fast to develop. I'm tired of banging my head against the wall with Struts and Hibernate.... I've been doing it for two days. It's not Hibernate, and it's not Struts, it's me... (thud, thud, thud).

Posted in Java at Dec 17 2003, 02:35:09 PM MST 15 Comments
Comments:

I've been twisting my head around the same thing. Not done anything with it yet though, and I'll have to try making an app before I figure how I'll end up. I still think the DAO-pattern probably would be a good thing though. I believe (from my small body og experience) that separating the code leads to fewer errors and is easier to maintain. But as you say, maybe it's too complicated. Maybe the easy solution works out the best.

Posted by Anders on December 17, 2003 at 10:40 PM MST #

I love heavily domain model based apps. Complete response here http://blogs.browsermedia.com/page/patrick/20031217#hibernate_pojos_and_actionforms

Posted by patrick on December 17, 2003 at 10:48 PM MST #

I don't think coupling your actions to Hibernate is a good idea.... unless you're building an example app for Hibernate :-) I need to take a look at this example (I looked at a pre-release version a month or so ago, but haven't seen the final product). I don't see a problem with having a REAL domain model and using it in your presentation layer though... converting back and forth is ugly, to me...

Posted by Jason Carreira on December 17, 2003 at 10:49 PM MST #

Just a note: The AdminApp should be a simple "not really layered" application. I agree that the separation is not perfect, but this wasn't the goal. Much more important is the Hibernate Interceptor and how Hibernate is configured/set up with the rest of the application. We will soon have a much more complex application (for our book) ready, I hope we can show better layer separation there. With AdminApp, we spent our time hunting down WW2 documentation (and downloads, the anon CVS is broken..), so it was more of a "get to know WW2" than anything else.

Posted by Christian Bauer on December 17, 2003 at 10:56 PM MST #

I think the real problem, at least in your case Matt, is the notion of persistence.User. This seems very wrong to me. What does a domain concept like 'User' have to do with a particular persistence logic? I would think that persistence.User should really be model.User. As for putting Hibernate code directly in your Actions I think it's a sure way to cause pain down the road if you ever decide to switch persistence frameworks. The problem here is people using Actions to contain business logic rather than just as a way to glue your OO-app to the web. Of course WW2 encourages this problem with the entire idea of a transaction interceptor.

Posted by Bo on December 17, 2003 at 11:43 PM MST #

I think Bo hit it right on the head. Here's some interesting reading Anemic Domain Model

Posted by John Cavacas on December 17, 2003 at 11:46 PM MST #

Interesting point Bo, I never even considered that. Sounds like I need for a bit of source tree re-factoring. I have to admit, as soon as I started just using the child POJOs (instead of converting them to ActionForms), things became <em>much easier</em> and Hibernate's <em>cascade="all-delete-orphan"</em> works just like the doco says. ;-)

Posted by Matt Raible on December 17, 2003 at 11:54 PM MST #

WebWork2/XWork actions don't HAVE to just be glue to tie your service layer to your web pages... XWork Actions can be used outside a Web context and can be used to encapsulate entry points to your system and reused in other places, such as via JMS... Either pattern is valid, since you're not tying yourself to the web.

Posted by Jason Carreira on December 18, 2003 at 03:22 AM MST #

If you want to see a better design consider the source to Roller. Do believe as long as this Hiberate WebWork app clearly shows you have to utilize hiberate from within an action then they have achieved their goals. It's not for the Hiberate team to design a common abstract persistence layer. Perhaps commons-database is a good name for a new jakarta project ;-)

Posted by Robert Nicholson on December 18, 2003 at 04:41 PM MST #

I thought the http://sourceforge.net/projects/xpetstore/ wasn't a bad demo of Webwork. Though, I would like to see a WebWork2 version of it. I mailed the author my modified code for hibernate 2, but the project does not look at active lately.

Posted by Matthew Payne on December 18, 2003 at 08:53 PM MST #

Matt,

One thing you might consider is checking out the Spring framework: http://www.springframework.org. I believe that there are some interesting things in the framework that may help you with the design/structure of your applications. They follow the DAO pattern, however lots of DB details like Transactions can be specified when you wire up the framework.

I also believe that it's very struts-friendly.

I'm using Hibernate + Spring + another web-component framework called Echo. So far the whole thing is jelling together quite nicely. I know that at any point I'll be able to drop in the Apache DBCP and not have to change one bit of my application code. Just have to re-wire the Spring framework which consists of one xml config file.

Personally I found Struts to be very confusing. Too much mucking around in XML files to hook everything up... But now that I'm much more experienced in Java and using XML files to define the hook ups in an application, I'll probably have to take a look at the framework again. Probably take a look at AppFuse as well! :)

Posted by mnickel on December 18, 2003 at 09:35 PM MST #

Arrgh... no preview button for comments...

That should be the http://www.springframework.org

My bad... sorry

Posted by mnickel on December 18, 2003 at 09:36 PM MST #

Can someone tell me who is it that is sending [email protected] as the From: for messages? Is it this blog? I would respectfully request that you don't do that. In my case it means that SpamAssassin learns a bunch of nonspam words for a message that is seen to be spam and now I have a Bayes database that thinks some terms are spam when they aren't. Is [email protected] a roller setting that isn't set perhaps?

Posted by Robert Nicholson on December 18, 2003 at 09:42 PM MST #

It is this blog - if you don't specify an e-mail address, that's the one it uses (I hardcoded it). Since I entered one on this comment, it's using that as the "From" address.

If I were smart (and had the time), I'd implement an optional comment alert system like this site (scroll down to "Comment alerts" heading).

Posted by Matt Raible on December 18, 2003 at 09:51 PM MST #

Yep, Spring will definately help you here. In fact the petclinic example that comes with the distro shows a good example implementation of the DAO pattern, giving you a completely abstracted persistence engine, with POJO beans being passed around. I still think the web application side of Spring is too messy though. I assume a similar thing could also be done with PicoContainer.

Posted by Sam Newman on December 19, 2003 at 02:25 PM MST #

Post a Comment:
  • HTML Syntax: Allowed