Thank you for contributing nothing to the discussion.
Rob Decker wrote:
Reading is good...let me know when you find the book that tells you how to
start with the correct model. I definitely want to get a copy ;)
Rob
@objectsource.org
----- Original Message -----
From: "David Haynes" <[EMAIL PROTECTED]>
To: "MyFaces Discussion" <[email protected]>
Sent: Thursday, September 01, 2005 9:32 AM
Subject: Re: JSF + Spring + Hibernate
Well, there was no smiley on this, so I will assume you are serious in
your question.
This may have been true for Thomas Edison, but I don't think you went
out and tried to build your own light bulb. Even if you did, you would
use the knowledge that you observed from looking at Edison's working
version (and via the patent would be able to see how Edison's worked).
I don't claim to be an Edison, but I can learn from them instead of
starting with first principles every time. There is a book series called
"Think in Java" that doesn't spend a lot of time documenting every
feature of the Java language but, instead, talks about how to think
about your problem in terms of the Java programming model. What I was
expressing was my desire for something similar for data-coupled web
applications.
-david-
Rob Decker wrote:
What makes you think you start with the correct model? You have to be
able
to create 2000 incorrect models; then you can create the correct one.
Just
ask Thomas Edison.
Rob
@objectsource.org
----- Original Message -----
From: "David Haynes" <[EMAIL PROTECTED]>
To: "MyFaces Discussion" <[email protected]>
Sent: Thursday, September 01, 2005 9:00 AM
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.
