1 Reply Latest reply on Jun 3, 2009 10:21 AM by Ansury

    Flex design pattern for BlazeDS transfer objects

    yanisss

      Dear Community,

      I have a question regarding the nature of objects transferd from BlazeDS backend to the Flex client.

      According to some adobe docs all the presentation logic should be in flex and BlazeDS should provide only services.

       

      The question is what kind of transfer objects should be used? with what level of abstraction?

       

      To make it more clear let's talk about a simple forum application like adobe forums.

      I have created a Forum service, which returns a Forum transfer object, which has a List of Threads, with each thread having a List of Messages.

      Flex gets the Forum transfer object and does all the presentaiton work.

       

      This is a very nice seperatin of concerns architecture BUT there are two major performance issues:

      - when the forum becomes bigger the transfer object will be huge

      - the flex will use huge client resources to create the presentation of the forum transfer object.

       

      So my question is what is your strategy/ design pattern for such a problem.

       

      An obvious answer would be create services that include the presentation logic and use transfor objects like ThreadListPage which will include only the first 10 threads.

       

      Thanks in advance

        • 1. Re: Flex design pattern for BlazeDS transfer objects
          Ansury Level 3

          I think you are going to get a few varied types of answers to a general question like this, but I will comment on a few things.  First, you should only be transmitting the data that you need to use or display to the user at the time.  If this forum was implemented in Flex (I wish) you wouldn't transfer the text for all the threads.  You might not transfer the thread text at all (just the subjects), you'd make calls back to the server to fetch that data when and if you need it.

           

          Also, I think you are overestimating the resources required for the Flex "presentation layer".  If you think about it, these workstations we have here are pretty idle most of the time when you're at a website.  Nowadays there's plenty of processing power just sitting there waiting, so as long as your design isn't flawed the CPU or memory are rarely going to be a bottleneck with Flex.

           

          The way I design, BlazeDS (or GraniteDS etc) should mostly just be "serving data".  There is some flexibility available, for example I don't see a problem with putting certain types of business rules (such as a limit on the number of results that can be recieved in a search) within server side code, and validation rules on the Flex side.  So there's not too many "industry standards" in Flex yet beyond maybe what's done in the various standard architectures, at least not that I'm aware of.

           

          You might find it beneficial to look into some of the various frameworks/architectures available like Cairngorm, Mate, Swiz, and so on.  Learning how they work (looking at examples) would probably answer some of your questions too.

          1 person found this helpful