Thank you Robert. I appreciate your response. I read your blog and it makes total sense to me as this is where I am coming from as well. I actually encourage anyone coming from the java world with an existing application (JSP/JSF/Struts/Hibernate/Spring/etc..) or not, to read the blog if you are interested in investigating flex.
Basically since my post, I have been playing with the Externalizable alternative and I managed to make a simple "CRUD" flex component based on the datagrid talking to a java service layer (spring/hibernate back end). It seems to be working fine. This solution will work fine for the "session closing problems and huge graphs" you mentioned in your blog. Also compared to the DTO/Assembler approach, it saves you from having to creating that significant layer. Now, where It falls short I believe, from what I can see today, is flexibility. In fact, with the Serialization approach, you can serialize an object 1 and only 1 way. If I only need the parent object in a request, but also needs its children in another request I can't do! Which is some of the flexibility that the DTO/Assembler approach provides certainely. Robert, I am going to try out the DTO/Assembler approach (Something tells me it is worth the initial investment). Any pointers, samples, whatever will be great. If you dont have anything, no worries, will figure it out. Thank you. And again, great Blog...! Will be adding my experience once I am done looking at the second alternative. Then....of course there is LifeCycle DS...I dont know if those problems also exist in Lifecycle...? Any LifeCycle DS /Spring/hibernate guru out there? Cheers, --- In flexcoders@yahoogroups.com, "Robert Cadena" <[EMAIL PROTECTED]> wrote: > > i should also have mentioned this: > > http://livedocs.adobe.com/blazeds/1/blazeds_devguide/serialize_data_3.html#303410 > > > > On Wed, Jun 4, 2008 at 7:22 PM, Robert Cadena <[EMAIL PROTECTED]> > wrote: > > > 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 > >> > >> > >> > >> > > >
