You're free to use a DTO layer or not, GraniteDS doesn't make this decision for you: if you use DTOs, you can generate your client-side (ActionScript3) beans from them with GraniteDS tools, but you have to deal yourself with uninitialized (lazy) properties. It can also lead to performance (deep-copying entities in/back to DTOs has a cost) and maintenance issues (you need to keep DTOs / entities sync)...
Personally, I avoid DTOs as well as any kind of intermediate objects when I can. But it's purely your call, depending on the kind of application you are developing. Thanks for the feedback! 2014-03-18 17:45 GMT+01:00 Gary Yang <[email protected]>: > For my experience, it would be better to keep this in mind when using > GraniteDS: > > there should be a layer where DB entity convert in/back to DTO, so that UI > logic won't be locked with DB schema. > > thanks. > > > On Tue, Mar 18, 2014 at 12:41 PM, Justin Ransom Dallas < > [email protected]> wrote: > > > I've always found GraniteDS to be far more involved than the BlazeDS lib. > > Just my opinion. > > > > > > On Tue, Mar 18, 2014 at 12:19 PM, Franck Wolff <[email protected]> > wrote: > > > > > Hi, > > > > > > We have republished and updated a quick migration guide from BlazeDS to > > > GraniteDS on our blog here: > > > > > > > > > http://www.granitedataservices.com/2014/03/18/migrating-from-blazeds-to-graniteds/ > > > > > > AFAIK, BlazeDS is dead for about 3 years, as well as Spring-Flex. On > the > > > other hand, GraniteDS is still very active and supports all new Spring > / > > > Java EE technologies. > > > > > > Just a quick reminder ;) > > > > > > Franck. > > > > > > > > > > > -- > > Justin Dallas > > Phone:814-880-5637 > > >
