As a part of application models, MVC is a phenomenol idea.We have models that are good self-contained bits of state, views that are good self-contained bits of UI, and controllers that self-contained bits of …??
Confused..!!!
Certainly it was not the first one to notice this, because the problem with MVC was to end up stuffing too much code into the controllers as we are not aware of it that where else to put it.
To overcome this as a part of MVC, there was a new pattern: MOVE. Models, Operations, Views, and Events.
Overview :
Lets define in a shorter view, this figure shows the basic structure of a MOVE application.
- Models can encapsulate everything that the application knows.
- Operations can encapsulate everything that the application does.
- Views will mediate between the application and the user.
- Events can join all these components together and safeguard them.
On the basis of avoiding over code in MVC, it was also peculiar noting that there were recommendations for what the objects of each type were allowed to do in MOVE . These were represented as arrows on the figure. For example, here views are allowed to listen to events that are emitted by models, operations were allowed to change models, but here models should not be referred to either views or operations.
Models
An archetypal model was a 'user' object. It usually contain at the very least an email address, probably a name and also a phone number.Its not insinificant to MVC
This MOVE application can model up only wrap knowledge. However, in addition to getters and setters, they can contain functions that make to check 'is this the user's password?', but might not contain functions that could make you save them to a database or upload them to an external API. That would be the an operation's job.
Operations
Logging a user in was a common operation for applications in MOVE. This is probably two sub-operations which are composed together: firstly get the email address and password from the respective user, and second have to load the 'user' model from the database and verify whether the password matches.
Perhaps, operations were the doers of the MOVE world. They were responsible for making changes to the models, for displaying the right views at the right time, and also for reacting to events triggered by user interactions. Within a better factored application, an each sub-operation can be run independently of its parent wihtout any support; that is why in the figure events flow upwards, and changes are maintained downwards.
The exciting aspect about this using operations in this way was that your whole application can itself be treated as an operation that is started when the program boots. This produce as many sub-operations as it needs, in which each concurrently existed sub-operation is runs in parallel, and exits the program when they were all finished.
This type may not be similar to MVC.
Views
Here, the login screen is a view which was responsible for displaying a few text boxes to the user at MOVE. When the user clicks the "login" button the view will allot a 'loginAttempt' event that contains the username and password that is typed by user.
Apart from MVC, everything which is visible to the user interact with, should be powered by a view. These not only display the state of the application in an understandable way, but also normalize the flow of incoming user interactions into meaningful events. Perspectively views does not change models directly, they simply emit events to operations, and does wait for modifications by listening to events emitted by the models in the part of MOVE.
Events
The 'loginAttempt' event is powered by the view when the user do click the login in the part of MOVE. Apart from these, when the login operation is finished, the 'currentUser' model will emit an event to notify your application that has modified.
Listening on events was what gives MOVE (and MVC) that the inversion of control which we need to allow the models to update views without the models being directly aware of which views they were updating. It is the most powerful abstraction technique, which is allowing components to be coupled together without interfering with each other
Conclusion:
See friends,I don't wish to misunderstood as indicating that MVC is worse; its truly has been an incredibly successful way to structure larger applications for the last few decades.
We also had seen more relevantly the work of MVC with ASP.NET which is mainly constituted with it in the framework of .NET.
From the time, it was invented however, new programming techniques also have become popular. Without any closures ,event binding could be much tedious; and without deferrables the idea of making individual operations as objects in their own perspectives right does not make much sense.
We also had seen more relevantly the work of MVC with ASP.NET which is mainly constituted with it in the framework of .NET.
From the time, it was invented however, new programming techniques also have become popular. Without any closures ,event binding could be much tedious; and without deferrables the idea of making individual operations as objects in their own perspectives right does not make much sense.
Ofcourse, MVC is an awesome, but it was designed with decades old technologies. MOVE is just a update to make good use of the new tools and techniques we have in our technical environment.
Also see : Work with ASP.NET
