I am an MVC purist, I always proceed as follows: Models should ONLY store information, particularly the state of the application and any data retrieved from disk or the network.
Views hold a reference to a model, watch it for updates, and respond to those updates by rendering the model in its current state. 'rendering' could refer to manipulating the display list in flash, outputting some text to stout (or trace) serving up some JSON from a server app, whatever way of expressing the state of the model your app requires. Views are also responsible for handling events that occur in their domain, and forwarding them to the appropriate Controllers. Controllers exist to manipulate models. The only acceptable way to alter a model is via a controller. Whether its storing data from a Web service in the model, or altering the state of the app in response to user interaction, the controllers hold all of the business logic that define how the app behaves. Ideally, in AS3, the models consist of no methods except accessors that retrieve values from private vars and store values there and notify subscribed views of the update. Event dispatcher is a fantastic base class for a model. Equally, wherever possible, a controller should only consist of methods. Properties are for the model. This sets up a unidirectional flow of interaction and display. The controller populates the model, the model notifies the views, the views change. The changed view incites some user interaction, the view tells the controller what the user wants to happen, and the controller alters the state of the model accordingly, which then notifies the views to change, and so on and so forth. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 On Feb 15, 2012, at 1:46 PM, "Merrill, Jason" <jason.merr...@bankofamerica.com> wrote: > Calculations would not be in the controller, they would be in the Model. > Sometimes you can justify them being in the view if it's related to the view. > Calculations are also in a Service class if they are part of a service in > some way. > > Jason Merrill > Instructional Technology Architect II > Bank of America Global Learning > > > > > > _______________________ > > -----Original Message----- > From: flashcoders-boun...@chattyfig.figleaf.com > [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of David Hunter > Sent: Wednesday, February 15, 2012 1:32 PM > To: Flash Coders List > Subject: [Flashcoders] MVC style > > Hello list, > > If I am making an application with MVC pattern and calculations are needed to > be performed on the data when the user interacts with the application, would > you: > > do the calculations in the Model? > > create a separate class that handles the calculations and puts the results in > the model? > > do the calculations in the Controller? > > looking forward to hearing people's thoughts on this, > > david > > -- > David Hunter > > www.davidhunterdesign.com > +44 (0) 7869 104 906 > _______________________________________________ > Flashcoders mailing list > Flashcoders@chattyfig.figleaf.com > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > ---------------------------------------------------------------------- > This message w/attachments (message) is intended solely for the use of the > intended recipient(s) and may contain information that is privileged, > confidential or proprietary. If you are not an intended recipient, please > notify the sender, and then please delete and destroy all copies and > attachments, and be advised that any review or dissemination of, or the > taking of any action in reliance on, the information contained in or attached > to this message is prohibited. > Unless specifically indicated, this message is not an offer to sell or a > solicitation of any investment products or other financial product or > service, an official confirmation of any transaction, or an official > statement of Sender. Subject to applicable law, Sender may intercept, > monitor, review and retain e-communications (EC) traveling through its > networks/systems and may produce any such EC to regulators, law enforcement, > in litigation and as required by law. > The laws of the country of each sender/recipient may impact the handling of > EC, and EC may be archived, supervised and produced in countries other than > the country in which you are located. This message cannot be guaranteed to be > secure or free of errors or viruses. > > References to "Sender" are references to any subsidiary of Bank of America > Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are > Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a > Condition to Any Banking Service or Activity * Are Not Insured by Any Federal > Government Agency. Attachments that are part of this EC may have additional > important disclosures and disclaimers, which you should read. This message is > subject to terms available at the following link: > http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you > consent to the foregoing. > _______________________________________________ > Flashcoders mailing list > Flashcoders@chattyfig.figleaf.com > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
