Programming ASP.NET MVC-Fundamentals of ASP.NET MVC(二）

The Model-View-Controller Architecture

The Model-View-Controller pattern is an architectural pattern that encourages strict
isolation between the individual parts of an application. This isolation is better known
as separation of concerns, or, in more general terms, “loose coupling.” Virtually all

aspects of MVC—and, consequently, the ASP.NET MVC Framework—are driven by
this goal of keeping disparate parts of an application isolated from each other.
Architecting applications in a loosely coupled manner brings a number of both short-and long-term benefits:
Development
Individual components do not directly depend on other components, which means
that they can be more easily developed in isolation. Components can also be readily
replaced or substituted, preventing complications in one component from affecting
the development of other components with which it may interact.
Testability
Loose coupling of components allows test implementations to stand in for “pro-duction” components. This makes it easier to, say, avoid making calls to a database,
by replacing the component that makes database calls with one that simply returns
static data. The ability for components to be easily swapped with mock represen-tations greatly facilitates the testing process, which can drastically increase the
reliability of the system over time.
Maintenance
Isolated component logic means that changes are typically isolated to a small num-ber of components—often just one. Since the risk of change generally correlates to
the scope of the change, modifying fewer components is a good thing!

The MVC pattern splits an application into three layers: the model, the view, and th
controller (see Figure 1-1). Each of these layers has a very specific job that it is respon
sible for and—most important—is not concerned with how the other layers do thei
jobs.

The Model

The model represents core business logic and data. Models encapsulate the properties
and behavior of a domain entity and expose properties that describe the entity. For
example, the Auction class represents the concept of an “auction” in the application

and may expose properties such as Title and CurrentBid, as well as exposing behavior
in the form of methods such as Bid().

 

The View

 

The view is responsible for transforming a model or models into a visual representation.
In web applications, this most often means generating HTML to be rendered in the
user’s browser, although views can manifest in many forms. For instance, the same
model might be visualized in HTML, PDF, XML, or perhaps even in a spreadsheet.
Following separation of concerns, views should concentrate only on displaying data
and should not contain any business logic themselves—the business logic stays in the
model, which should provide the view with everything it needs.

 

The Controller

The controller, as the name implies, controls the application logic and acts as the co-
ordinator between the view and the model. Controllers receive input from users via the
view, then work with the model to perform specific actions, passing the results back to
the view.