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]>:
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.
>>
>>
>>
>>
>
>
>
>
>
