Enrique:
That sounds promising. I am also doing my PMP prep and am trying to put
together a JSF/Hibernate application now, so I am a bit behind you on
the learning curve. I have also been thinking about how a web
application is really a finite state automata and how the diagramming
tools from those may be used for modeling. It's early days on that train
of thought though.
-david-
Enrique Medina wrote:
You're absolutely right.
I'm currently very busy in preparing my PMP and finishing my JSF
application, but I will be delighted to transfer all my experience and
knowledge in this matter as soon as a I find a couple of free weekends
(I was exactly in the same position that you are now when I began some
time ago with all this technology, so I can precisely imagine the kind
of tutorial you are waiting for ;-)
Sorry, but I can only ask for patience right now.
2005/9/1, David Haynes <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
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] <mailto:[EMAIL PROTECTED]>
>
>
>
>>-----Original Message-----
>>From: news [mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>] On Behalf Of Werner Punz
>>Sent: Thursday, September 01, 2005 3:56 AM
>>To: [email protected] <mailto:[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.
>>
>>
>>
>>
>
>
>
>
>
