Sounds helpful. I would certainly be interested in reading about what
you have discovered. I took some of Rob Decker's advice and re-read big
chunks of Will Iverson's "Hibernate: A J2EE Developer's Guide". While it
covers Hibernate 2, most of his advice is applicable to Hibernate 3 as
well. The only thing I found odd was that he would present the hbm.xml
file and *then* show the associated UML some pages later. Maybe its just
me, but I would have probably put them the other way around.
I am now at the stage where I have a JSP/Hibernate solution with the
backing beans working the way I would expect them to. The next stage is
to replace the JSP with JSF and see how that goes. I am starting to
build a methodology for development that seems to work for me. It starts
with making changes to the UML model, then moving those changes into the
hibernate hbm.xml (adding to the hibernate.cfg if required), then
working up the bean (I know I could do this via a hibernate tool but I
want to work with the beans directly for a while), and then, finally,
encorporating the bean into the web pages. JSF, as I understand it, will
allow me to remove the useBean references since it automatically invokes
the creation of the bean upon first access.
All good stuff and certainly a learning exercise for me. After I get all
this sorted out, I plan to introduce Spring into the mix (baby steps,
baby steps) to see how that affects everything.
-david-
Joshua Davis wrote:
Well, If I can manage to learn JSF well enough I should be able to write
something up about how to use the backing beans with Hibernate. Maybe I
will re-use Spring's Hibernate support eventually, but for now I'm just my
own simplistic Hibnerate-JSF integration so I can concentrate on learning
JSF.
-----Original Message-----
From: David Haynes [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 01, 2005 9:00 AM
To: MyFaces Discussion
Subject: Re: JSF + Spring + Hibernate
I'm going through that phase now waiting for the epiphany to strike...
What I would really like is an article about thinking in ORM
(ala Hibernate or EJB) that doesn't talk about how the APIs
are put together but, instead, deals with concepts like: this
is how to think about modeling in ORM, this is how to
structure stuff in Hibernate for a data-backed bean, or this
is how to set up your source area to make all this a little
clearer. A diagrammatic modeling method would also be of
great value. Heck, even a suggested naming practice would be
nice! Is that XxxAction, XxxController, XxxBean,
XxxBackingBean, XxxModel, XxxDAO, etc.?
Maybe I'm being a little selfish, but it seems to me that the
majority of postings about backing-store issues are from poor
sods such as myself who are trying to simply create
data-coupled web applications that won't fall apart with the
first change. (i.e. that use well structured toolkits to
assist). With all the options that are available, it is
difficult to get one scenario working, let alone being able
to compare solutions in some meaningful way. Every time an
issue comes up, the answer seems to be to add another
software layer, from another development group, with another
model/philosophy for how the solution should be coded. Having
reference implementations helps to some degree, but if you
are missing the fundamental concepts, the reference
implementations can end up being confusing since they tend to
highlight the differences/features of the particular
implementation over the competition. Even the books with
implementations in them tend to dive directly into the code
without addressing the modeling aspect and the thinking that
goes into creating the correct model to begin with.
-david-
Joshua Davis wrote:
Sorry 'bout the head banging! :( If there's anything I can
do to help,
let me know.
You are absolutely, positively 100% correct about 'getting a
grip' on
Hibernate.
It's actually more fundamental than that: You need to have a good
understanding of ORM in general in order to use Hibernate (or EJB
Entities, or TOPLink, etc.) effectively. For me,
understanding ORM was
a 'leap' that was similar to when I went from structured
programming to OOP.
[EMAIL PROTECTED]
-----Original Message-----
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Werner Punz
Sent: Thursday, September 01, 2005 3:56 AM
To: [email protected]
Subject: Re: JSF + Spring + Hibernate
One of the reasons why I am not that much a friend of Hibernate
anymore.
I did 4 projects with it, and the problems always were the same...
Overkill in mapping details, Session handling and choking
on pojos in
which made things more complicated than they should be, failurs in
dependency resolution on write over more complicated data
structures,
which then had to be resolved manually...
Constant banging the heads on small stuff, like having a clean and
proper way to resolve m:n issues. Sometimes there are errors where
Hibernate simply does nothing but does not even throw errors.
Dont get me wrong, Hibernate is an excellent tool, and
basically has
solved most of not all issues you constantly run into with Object
Relational mappins and OODBs, but it is options overkill and
definitely not easy to handle.
I am not sure which is more complicated the EJB approach or the
options overkill in Hibernate, which does not force you
into anything,
but often simply fails with leaving you standing in the rain.
My opinion is, there must be some kind of middle way, to give you
enough flexibility but does not push you into such a huge complex
layer, Hibernate has evolved into, also 90% of the main problem you
constantly have with hibernate is the complicated way the session
handles the pojos... Dump the wrong pojo into the session
and you get
a object has been used failure.... Run out of the session hibernate
chokes on lazy access instead of trying to resolve the problem by
opening another one and trying to load the rest automatically...
I would say, Hibernate is the worst/best working solution
you can get
from OSS in regards to ORM mapping, but one thing is for
sure, it made
things definitely not easier, although if you have a grip
on it, you
can save a lot of time, but aquiring the grip is a hard task, even
with the excellent docs.
