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