ing interactive applications. In his design, applications were broken into three
types of components: models, views, and controllers.
times this state is transient, lasting for just a couple of interactions with the
user. Sometimes the state is permanent and will be stored outside the appli-
cation, often in a database.
A model is more than just data; it enforces all the business rules that applyto that data. For example, if a discount shouldn’t be applied to orders of less
than $20, the model will enforce the constraint. This makes sense; by putting
the implementation of these business rules in the model, we make sure that
nothing else in the application can make our data invalid. The model acts as
both a gatekeeper and a data store.
2.The view is responsible for generating a user interface, normally based ondata in the model. For example, an online store will have a list of products
to be displayed on a catalog screen. This list will be accessible via the model,
but it will be a view that accesses the list from the model and formats it for
the end user. Although the view may present the user with various ways of
inputting data, the view itself never handles incoming data. The view’s work
is done once the data is displayed. There may well be many views that access
the same model data, often for different purposes.
In the online store, there’ll be a view that displays product information on a catalog page and another set
of views used by administrators to add and edit products.
3.Controllers orchestrate the application. Controllers receive events from theoutside world (normally user input), interact with the model, and display anappropriate view to the user.This triumvirate—the model, view, and controller—together form an architec-ture known as MVC. MVC is shown in abstract terms in Figure 2.1.
MVC was originally intended for conventional GUI applications, where devel-opers found the separation of concerns led to far less coupling, which in turnmade the code easier to write and maintain. Each concept or action wasexpressed in just one well-known place. Using MVC was like constructing askyscraper with the girders already in place—it was a lot easier to hang therest of the pieces with a structure already there.In the software world, we often ignore good ideas from the past as we rushheadlong to meet the future. When developers first started producing webapplications, they went back to writing monolithic programs that intermixedpresentation, database access, business logic, and event handling in one bigball of code. But ideas from the past slowly crept back in, and folks startedexperimenting with architectures for web applications that mirrored the 20-year-old ideas in MVC. The results were frameworks such as WebObjects,Struts, and JavaServer Faces. All are based (with varying degrees of fidelity)on the ideas of MVC.
Ruby on Rails is an MVC framework, too. Rails enforces a structure for your
application—you develop models, views, and controllers as separate chunks offunctionality, and it knits them all together as your program executes. One of
the joys of Rails is that this knitting process is based on the use of intelligent
defaults so that you typically don’t need to write any external configuration
metadata to make it all work. This is an example of the Rails philosophy of
favoring convention over configuration.
In a Rails application, an incoming request is first sent to a router, which
works out where in the application the request should be sent and how the
request itself should be parsed. Ultimately, this phase identifies a particular
method (called an action in Rails parlance) somewhere in the controller code.
The action might look at data in the request, it might interact with the model,
and it might cause other actions to be invoked. Eventually the action prepares
information for the view, which renders something to the user.
＠Agile Web Development with Rails，Third Edition
转载于:https://www.cnblogs.com/binterminator/articles/1629977.html