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