ASP.NET MVC – Nerdinner - notes

The blog record any valuable point from the free book. 《Professional ASP.NET MVC 1.0》!

The blog write by volnet.

1.Page 12/196

ASP.NET MVC projects by default have six top-level directories:

Directory	Purpose
/Controllers	Where you put Controller classes that handle URL requests
/Models	Where you put classes that represent and manipulate data
/Views	Where you put UI template files that are responsible for rendering output
/Scripts	Where you put JavaScript library files and scripts (.js)
/Content	Where you put CSS and image files, and other non-dynamic/non-JavaScript content
/App_Data	Where you store data files you want to read/write.

ASP.NET MVC does not require this structure. In fact, developers working on large applications will
typically partition the application up across multiple projects to make it more manageable (for example:
data model classes often go in a separate class library project from the web application). The default
project structure, however, does provide a nice default directory convention that we can use to keep
our application concerns clean.

2.Page 28/196

In a model-view-controller framework the term “model” refers to the objects that represent the data of
the application, as well as the corresponding domain logic that integrates validation and business rules
with it. The model is in many ways the “heart” of an MVC-based application, and as we’ll see later fundamentally drives the behavior of it.

3.Page 31/196

By default the LINQ to SQL designer automatically "pluralizes" table and column names when it creates
classes based on a database schema. For example: the "Dinners" table in our example above resulted in
a "Dinner" class. …

By default the LINQ to SQL designer also inspects the primary key/foreign key relationships of the tables,
and based on them automatically creates default "relationship associations" between the different
model classes it creates. For example, …

4.Page 42/196

We can use .NET’s regular expression support to implement this phone validation support. Below is a
simple PhoneValidator implementation that we can add to our project that enables us to add countryspecific
Regex pattern checks:

 

Click here to get code!

All these code is the same as before. (Click here to collapse!)

public class PhoneValidator {
static IDictionary<string, Regex> countryRegex =
    new Dictionary<string, Regex>() {
        { "USA", new Regex("^[2-9]\\d{2}-\\d{3}-\\d{4}$")},
        { "UK", new
            Regex("(^1300\\d{6}$)|(^1800|1900|1902\\d{6}$)|(^0[2|3|7|8]{1}[0-
                9]{8}$)|(^13\\d{4}$)|(^04\\d{2,3}\\d{6}$)")},
                { "Netherlands", new Regex("(^\\+[0-9]{2}|^\\+[0-
                9]{2}\\(0\\)|^\\(\\+[0-9]{2}\\)\\(0\\)|^00[0-9]{2}|^0)([0-9]{9}$|[0-9\\-
                \\s]{10}$)")},
    };
    public static bool IsValidNumber(string phoneNumber, string country) {
        if (country != null && countryRegex.ContainsKey(country))
            return countryRegex[country].IsMatch(phoneNumber);
        else
            return false;
    }
    public static IEnumerable<string> Countries {
        get {
            return countryRegex.Keys;
        }
    }
}

5.Page 43/196

Because our validation and business rules are implemented within our domain model layer, and not
within the UI layer, they will be applied and used across all scenarios within our application. We can
later change or add business rules and have all code that works with our Dinner objects honor them.
Having the flexibility to change business rules in one place, without having these changes ripple
throughout the application and UI logic, is a sign of a well-written application, and a benefit that an MVC
framework helps encourage.

6.Page 44/196

Web-based MVC frameworks map URLs to server code in a slightly different way. Instead of mapping
incoming URLs to files, they instead map URLs to methods on classes. These classes are called
“Controllers” and they are responsible for processing incoming HTTP requests, handling user input,
retrieving and saving data, and determining the response to send back to the client (display HTML,
download a file, redirect to a different URL, etc).

7.Page 50/196

Separating our controller logic from our view rendering brings several big benefits. In particular it helpsenforce a clear "separation of concerns" between the application code and UI formatting/rendering code. This makes it much easier to unit-test application logic in isolation from UI rendering logic. It makes it easier to later modify the UI rendering templates without having to make application code changes. And it can make it easier for developers and designers to collaborate together on projects.

8.Page 77/196

You might ask – why are we using a single URL and differentiating its behavior via the HTTP verb? Why not just have two separate URLs to handle loading and saving edit changes? For example:
/Dinners/Edit/[id] to display the initial form and /Dinners/Save/[id] to handle the form post to save it?
The downside with publishing two separate URLs is that in cases where we post to /Dinners/Save/2, and then need to redisplay the HTML form because of an input error, the end-user will end up having the /Dinners/Save/2 URL in their browser’s address bar (since that was the URL the form posted to). If the end-user bookmarks this redisplayed page to their browser favorites list, or copy/pastes the URL and emails it to a friend, they will end up saving a URL that won’t work in the future (since that URL depends on post values).
By exposing a single URL (like: /Dinners/Edit/[id]) and differentiating the processing of it by HTTP verb, it is safe for end-users to bookmark the edit page and/or send the URL to others.

9.Page 96/196

You might ask – why did we go through the effort of creating a <form> within our Delete confirmation screen? Why not just use a standard hyperlink to link to an action method that does the actual delete operation?
The reason is because we want to be careful to guard against web-crawlers and search engines discovering our URLs and inadvertently causing data to be deleted when they follow the links. HTTPGET based URLs are considered “safe” for them to access/crawl, and they are supposed to not follow HTTP-POST ones.
A good rule is to make sure you always put destructive or data modifying operations behind HTTP-POST requests.

10.Page 129/196

For Internet web applications, the most common authentication approach used is called “Forms Authentication”. Forms Authentication enables a developer to author an HTML login form within their application, and then validate the username/password an end-user submits against a database or other password credential store. If the username/password combination is correct, the developer can then ask ASP.NET to issue an encrypted HTTP cookie to identify the user across future requests.

另外刚刚发现还有个中文版的链接：http://bit.ly/uyAtI