Why do you need design patterns or “What is MVC?”

The most important thing in all frameworks is that they all dictate the rules for creating an application. If you have never used any framework in your applications, then either they are too small and you did not encounter the problem of increasing chaos in the code, or your time just did not come :) And in the end, the application created according to the rules of the framework will definitely get the right shape. Isn't that what we all want? A beginner in programming, starting the study of a framework, automatically begins to think correctly, thereby adopting the experience of previous generations and discovering a smoother way forward. In any case, the only way to create large, extensible and modular applications is to use the framework.

So, let's begin…

MVC "Model-view-behavior" === "Model-view-controller".
')
Now close your eyes and imagine the work of your application. Presented? ... so, try to conditionally break this process into three abstract logical parts:

Collect all the methods of your application that process all visual components, methods that have knowledge of the visual element, which move them around the screen, etc. Mentally combine them into one part of the program, this will be (Presentation).

Further. Collect all the methods of your application that deal with the logic of the application, methods that have knowledge of what and how to do. Behavior of components of the application. Mentally combine them into one part of the program, this will be (Model).

The third, but no less important part, these are the methods in which the model behavior itself is implemented. The so-called "controller". In general, these are any methods that are called for example the event of losing the game, let's say: function onLoseLevel (e: SomeEvent): void. In this case, this method is the behavior of the model of your application in case of loss. As soon as you lose a level, a specific method is called that implements the behavior of the application in a particular case. So, collect all the methods that implement the behavior in one pile
this will be the third logical part of the MVC concept, (Controller).

For those who did not fully understand and did not answer the question why this whole partition is needed: In order to reduce the code linkability, i.e. changing something in the project changes will not affect the other part of the program. Thus, our application can be more flexible and consist of independent modules and adapted to refactoring.

Implementing the MVC concept using the example of the HellowWorld application

HelloWorld.as:

package { import flash.display.Sprite; import flash.events.Event; import flash.text.TextField; public class HelloWorld extends Sprite { private var viewComponent :TextField; public static var model :Model; public static var view :View; public static var controller :Controller; /** * Constructor * */ public function HelloWorld() { /*Add listener to catch an event to add to stage * */ addEventListener(Event.ADDED_TO_STAGE, showTextHandler); /* Creation one view component as TextField * */ viewComponent = new TextField(); addChild(viewComponent); /*Creation the Model * */ model = new Model(); /*Creation the View and giving viewComponent into constructor * */ view = new View(viewComponent); /*Creation the Controller * */ controller = new Controller(); } /*Set the command to handling on the event * */ protected function showTextHandler(event:Event):void { controller.showTextFieldCommand(); } } } 

Model.as

 package { public class Model { private var _textString :String = "Hello World!"; public function Model() { } public function get textString():String { return _textString; } public function set textString(value:String):void { _textString = value; } } } 

View.as:

 package { import flash.text.TextField; public class View { private var _view:Object; public function View(viewObj:Object) { view = viewObj; } /*Method to change text field in the view component * */ public function changeView(str:String):void { view.text = str; } public function set view(value:Object):void { _view = value; } public function get view():Object { return _view; } } } 

Controller.as:

 package { public class Controller { public function showTextFieldCommand():void { var str:String = HelloWorld.model.textString; HelloWorld.view.changeView(str); } } } 

OK. Let us analyze what is happening here. There is the main class of the application: HelloWorld.as which is responsible for everything. In it, we create a single visual component of the TextField type (text field), as well as instances of Model.as, View.as and Controller.as. Now how does all this relate?

To begin with, we will transfer the visual component to our View control by passing it to the constructor:

  view = new View(viewComponent); 

artemfedorov.com/?p=64
Now our View knows about the component.
Next, add a method to the View with which it can affect the component:

  public function changeView(str:String):void { view.text = str; } 

here, only a new value of the String type is assigned to the text field of the component.

Our Model in this example contains only knowledge of the value of a string variable, and business logic is limited to this.

  private var _textString :String = "Hello World!"; 

The Controller also contains only one command that receives the value from the Model and tells the View what to do:

  public function showTextFieldCommand():void { var str:String = HelloWorld.model.textString; HelloWorld.view.changeView(str); } 

Further, the final touch without which nothing will work this event. Here, for the example of the event, I selected the event that occurs when adding on the stage and added a listener:
addEventListener (Event.ADDED_TO_STAGE, showTextHandler);

I attached a command to this event implementing the behavior of my application:

  protected function showTextHandler(event:Event):void { controller.showTextFieldCommand(); } 

www.artemfedorov.com
That's all!