Hi Mehdi, this is just my current opinion on the subject: create data transfer objects for your domain objects (your hibernate pojos). Which is basically the first solution you proposed. Use custom assemblers to create DTOs from your DOs .
This is my current opinion on the subject. There are a few criteria for that I've come up with for doing this extra amount of work, but the one that I've found most compelling is this: **your domain model, or domain objects, or hibernate objects, whatever you want to call them, have deep or complex hierarchies that would be expensive to recreate when BlazeDS transfers the object over the wire**. If your graph is deep you'll end up pulling out a bunch of objects you might not need on the front end. If you close the session early you'll end up with unavailable session exceptions and you may have to adopt the open session in view pattern for the message broker servlet, which is less than ideal because you'd have to configure it for the servlet path and it might be too difficult to configure it per method invocation. Check out my blog post on the subject: http://www.machine501.com/blog/2008/06/03/useful-patterns-for-blazeds/ It's painful, and I think it is something that stops people from adopting blazeds. it would be ideal if there was a way to configure object factories in BlazeDS so that it could deal with your problem of argument constructors, and, if it was possible to give blazeds hints about the properties it should attempt to serialize on a per-method manner. cheers /r On Wed, Jun 4, 2008 at 2:20 AM, Mehdi <[EMAIL PROTECTED]> wrote: > I am relatively new to the flex world. I am from the Spring/Hibernate > world. > In Hibernate, the POJO object or domain object , or simply beans that > you use to persist you object into the database does not have to > follow the bean definition/contract, i.e: public default constructor > with getter/setters. There are good reasons behind creating those kind > of 'hibernate beans' (I will call them that way for lack of a better > name). In fact, only defining a one-parameter constructor (i.e. > omitting the default one) guaranties you that your client cannot > invoke your API without that needed parameter. Likewise, exposing only > the getters for some private member variables (without the setters) > makes sense when you don't want that variable to ever change, > etc....hibernate manage to access these fields using cglib, and other > tricks. > > Now, my understanding of Flex and how remote services work (from what > I could see in all the samples around about hibernate/spring), is that > your java server bean get proxied 'dynamically' or 'statically' (via > an Actionscript class object) according to the rule: Only "values > found in public bean properties with get/set methods and public > variables " are being copied over to the client proxy object. Which > means that if I dont have a default constructor I am toast. It also > means that my public getVar() (without a setVar()) from my 'hibernate' > bean/POJO will never make it into my client proxy. An example of > getVar(), is simply getdbID(), where the dbID is an > autocincrement/sequence for example? > > This is creating me tons of problems, because we arlready have a well > rounded/tested server API and we already have a JSF implementation > using it....Re-writing a new one using flex is more something I am > pushing for to prove that we can get better UI,etc.... > > What is flex/BlazeDS solution for fixing this case? > One solution that comes to mind (not very bright, but should work) is > to build a whole slew of plain java bean objects ( 1 for each of > the'hibernate' bean) to ensure the translation on both side between > the 'hibernate bean' and the 'expected' bean from flex. From the > server to the client, the new bean would copy the content of the > hibernate bean and return that 'proper' beans back to flex. On the way > out (from the client to the server), it would have to recreate the > hibernate bean before feeding it to the API and hibernate).... It's > probably not the best solution, especially considering that eventually > as some point, I will need to define another set of those > objects(beans) on the flex side, using actionscript (I think these are > what you guys call VOs) in order to do strong typing in flex........ > I must be missing something! can't be that complicated > > Another possible solution (is it? not sure anymore) I believe is to > play with the java/flex Externalizable/IExternalizable, but that means > changing all my beans on the server (as I will need to implement > Externalizable as per what I understood from the readings). > > Isn't there something that I can do on the client only??? How do you > guys handle that? > > Any input would be valuable. > Thank you, > > > ------------------------------------ > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Search Archives: > http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups > Links > > > >
