MVC frame work

[manikesh_verma]

hi every one

can u tell me how MVC frame work increases the efficiancy of softwares.

and what is the main job of controller.

[img]smileys/smiley19.gif[/img]its urgent so plz make it fast.

[sowmya571]

hello





Model-view-controller (MVC) is a software architecture that separates an application's data model, user interface, and control logic into three distinct components so that modifications to one component can be made with minimal impact to the others.



MVC is often thought of as a software design pattern.
However, MVC encompasses more of the architecture of an application
than is typical for a design pattern. Hence the term architectural
pattern may be useful (Buschmann, et al 1996), or perhaps an aggregate design pattern.




In broad terms, constructing an application using an MVC architecture involves defining three classes of modules.

[*]Model: This is the domain-specific representation of the
information on which the application operates. The model is another
name for the domain layer. Domain logic adds meaning to raw data (e.g.
calculating if today is the user's birthday, or the totals, taxes and
shipping charges for shopping cart items).[*]View: This renders the model into a form suitable for interaction, typically a user interface element. MVC is often seen in web applications, where the view is the HTML page and the code which gathers dynamic data for the page.[*]Controller: This responds to events, typically user actions, and invokes changes on the model and perhaps the view.[*]Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention this data access layer.[/list]


It's common to think of an application as having three main layers:
presentation (UI), domain, and data access. In MVC, the presentation
layer is split into controller and view. The most important separation
is between presentation and domain; the V/C split is less so.



Though MVC comes in different flavors, control flow generally works as follows:

1. The user interacts with the user interface in some way (e.g., user presses a button)
2. A controller handles the input event from the user interface, often via a registered handler or callback.
3. The controller accesses the model, possibly updating it in a way
   appropriate to the user's action (e.g., controller updates user's shopping cart). Complex controllers are often structured using the command pattern to encapsulate actions and simplify extension.
4. A view uses the model to generate an appropriate user interface
   (e.g., view produces a screen listing the shopping cart contents). The
   view gets its own data from the model. The model should have no direct
   knowledge of the view. However, the observer pattern
   can be used to provide some indirection between model and view,
   allowing the model to notify interested parties of a change. A view
   object can register itself with the model and listen for changes but
   the model itself remains view-agnostic. The controller does not pass
   domain objects (the model) to the view although it might issue a
   command telling the view to update itself.
5. The user interface waits for further user interactions, which begins the cycle anew.


[edit]








Advantages and disadvantages





Although widely used, MVC has both advantages and disadvantages
compared to other design options, and individual circumstances should
be used to choose the most appropriate design.


[edit]








View instability vs. model stability





If constructed correctly, models can enjoy a fair degree of stability
(owing to the stability of the domain model), whereas user interface
code usually undergoes frequent and sometimes dramatic change
(typically because of usability problems, the need to support growing
classes of users, or simply the need to keep the application looking
"fresh"). Separating the view from the model makes the model more
robust, because the developer is less likely to "break" the model while
reworking the view.



Attempting to join these two worlds in a hand coded method without
architecture is very common, and results in the model object being
polluted with knowledge of the interface, and vice-versa. This makes
the code very inflexible and difficult to maintain. For this reason
(among others), many programming shops develop the user interface
design early in the process of design, and freeze the interface early.
The unfortunate side effect of this is that the domain of the problem
often isn't clearly understood by the programmers until late in the
implementation process. Thus, just at the time that the developers are
finally competent to create a good interface, they are kept from
changing it. MVC models allow the code to be more flexible later in the
development process, allowing for changes to be made at the time it
makes sense to make them.


[edit]








Event driven





In contrast, objects in object oriented programming are composed of
methods and data members that attempt to model something from the
domain of interest. The best models are fully encapsulated, meaning
that they implement every aspect of that real world object of interest
to the domain of interest, and that they don't have any extra code that
doesn't model the real world. Encapsulation also means that the class
is implemented in such a way that the internal representation of data
is not exposed to the user of the object.



The impedance mismatch
between these two worlds, that of events, and that of objects, is
something that's been recognized for a long time. Getting these two
worlds to cooperate requires a lot of 'glue code'.



The 'model-view-controller' paradigm introduces the
controller object in between the view (the GUI class) and the model
(the object) to communicate between the other two objects. The actual
implementation of the controller object can vary quite a bit, but the
idea of an object to 'transform' events to changes in data and
execution of methods is the essence of this pattern.

Just because an application responds to events does not mean it is
"event driven". Event driven means it spends much of its time waiting
for an event and then takes action if and when an event occurs.
Contrast this with some programs that do not respond to events at all,
but simply do their job and terminate. For example, an operating system
command to display the current time. It displays the time and is done;
it does not wait for events.



well the use of controller is jus handles the request and response .. just as browser for ur application ..



bye



sowmya