8 Replies Latest reply on Jun 9, 2011 9:41 AM by pauland

    MVC Paradigm

    daslicht Level 2

      Hello,

       

      which part of the MVC paradigm would be consist of the Remote Object ?

       

      Regards

      Marc

        • 1. Re: MVC Paradigm
          pauland Level 4

          What part do you think it is?

          • 2. Re: MVC Paradigm
            UbuntuPenguin Level 4

            I would say it belongs int the realm of the controller/presenter.  I say this because many services are called due to user gestures, such as loading information on a widget after a user have clicked its image.  I use Mate and mostly the presentation model, but I would love to hear other people's thoughts on Flex architecture.

            1 person found this helpful
            • 3. Re: MVC Paradigm
              pauland Level 4

              I was trying to make the OP think about it..

               

              Not that I would agree with you Mr Penguin!

              • 4. Re: MVC Paradigm
                daslicht Level 2

                I have thought about it and actually having it in the controller.

                 

                But in some cases it might be also usefull to place the remoteobject in the model where for example the runtime data resides.

                 

                Thats why I am asking for your opinion here.

                • 5. Re: MVC Paradigm
                  pauland Level 4

                  OK, I generally see remote objects as being associated with the model, but only as a part of the implementation of the model - a convenience to allow the model access to a remote service or datastore. A "helper" to the model, in effect.

                   

                  I don't see that remote objects should be exposed to the UI or controller.

                   

                  UbuntuPenguin suggests that they are associated with the controller/UI because the UI initates the use of a service. I don't really agree with that because I think UIs shouldn't be aware of how the data they need to display is required. They need no knowledge of the underlying mechanism, nor does the controller.

                   

                  Only theModel needs to know the detail of how to retrieve the data it will expose for the UI.

                  1 person found this helpful
                  • 6. Re: MVC Paradigm
                    daslicht Level 2

                    Thank you for you replies !

                    • 7. Re: MVC Paradigm
                      UbuntuPenguin Level 4

                      Just to clarify, when I said controller/presenter I meant the c and p in MCC/MVP, so the UI has no clue that services exists or the logic under which they are accessed.  Here is an example of how I use a service call, remote object.  Feel free to point out any shortcomings or ask questions.

                       

                      WidgetListPresenter.as  // is injected into a view containing a group of widgets ( list, button bar, dropdown )

                      ...

                      //Injected

                      [Bindable] public var widgetStubsCollection:ArrayCollection;

                      //The selected widget in the view

                      [Bindable] public var selectedWidgetStub:WidgetStub;

                       

                      public function handleWidgetClick( event:Event ):void

                      {

                           if( selectedWidgetStub != null )
                          {
                               var widgetId:String = selectedWidgeStub.widgetId;
                               var wEvent:WidgetEvent = new WidgetEvent(WidgetEvent.WIDGET_SELECTED);
                               wEvent.widgetId = widgetId;

                              dispatcher.dispatchEvent(  wEvent );
                          }

                      }

                       

                      The actual remote object exists in our EventMap but the return is handled by the model.  Now if I didn't have my RO in the EventMap, I would keep it in the model.  I would simply have my wEvent go to a function named "handleWidgetSelection( wEvent:WidgeEvent )" and then make the service call from there.  Now that I think about it, having the event go straight to the model affords me the option of "caching" preloaded widgets.

                       

                       

                      WidgetModel.as

                      [Bindable] public var selectedWidget:Widget;

                      [Bindable] public var widgetCreationDate:Date;

                      [Bindable] public var widgetCount:int;

                      [Bindable] public var widgetName:String;

                       

                      public function handleWidgetServiceReturn( value:Object ):Object

                      {

                       

                        // All of this could be done in the "public function set selectedWidget( value:Widget  ):void

                        // but that is a lot of code for a forum post

                         selectedWidget = value as Widget;

                         if( selectedWidget != null )

                         {

                             widgetCreationDate = selectedWidget.creationDate;

                             widgetCount = selectedWidget.count;

                             ....

                         }

                         else

                         {

                            //set to null state or throw error

                           // or alert box

                         }

                         return value;

                      }

                       

                       

                       

                       

                      I welcome any tips, advice, or admonishments you may have.  I really wish Flex application architecture was discussed a little more, from my short experience there is absoluetly NOTHING more devastating to a projects quality, budget , maintenance, total cost of ownership and timeliness as bad architecture.  It seems like software engineering is one of the few fields where one or two misguided individuals in the wrong positions can destroy a project of 12 people.

                      • 8. Re: MVC Paradigm
                        pauland Level 4

                        UbuntuPenguin wrote:


                        I welcome any tips, advice, or admonishments you may have.

                         

                        No admonishments. There are many ways to skin a cat. The most important thing is that the UI shouldn't be aware of the RO mechanism or be handling them.

                         

                        It seems like software engineering is one of the few fields where one or two misguided individuals in the wrong positions can destroy a project of 12 people.

                         

                        Actually managers can be rather good at messing up projects. I think they train for it!

                         

                        I'm not a believer that there exists a silver bullet framework or way of accomplishing things. I try and keep things as simple as I can. Some people build a career of being an evangelist for some framework or software process or language and then it's a bit like making a guilded hammer and everything must be turned into a nail.