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.
Thenof 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,
etchibernate 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()
