There is something on the wiki already...
it just needs a little bit more flesh and a few corrections...
But I would say one step at a time, both JSF and Hibernate are
huge frameworks, so it is better to concentrate on one
and then on the other, before you combine both.
Werner
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.
