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.