That's the conclusion I came to. I did JSP/Hibernate first and will then
change the JSP to JSF as the next stage.
-david-
Werner Punz wrote:
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.
