Pro ASP.NET MVC Framework phần 5 pot

■Note As you’ll learn in Chapter 14, you deploy an MVC application by copying much of this folder struc￾ture to your web server. For security reasons, IIS won’t serve files whose full paths contain web.config,

bin, App_code, App_GlobalResources, App_LocalResources, App_WebReferences, App_Data, or

App_Browsers, because IIS 7’s applicationHost.config file contains <hiddenSegments> nodes hiding

them. (IIS 6 won’t serve them either, because it has an ISAPI extension called aspnet_filter.dll that is

hard-coded to filter them out.) Similarly, IIS is configured to filter out requests for *.asax, *.ascx,

*.sitemap, *.resx, *.mdb, *.mdf, *.ldf, *.csproj, and various others.

Those are the files you get by default when creating a new ASP.NET MVC web application,

but there are also other folders and files that, if they exist, can have special meanings to the

core ASP.NET platform. These are described in Table 7-2.

Table 7-2. Optional Files and Folders That Have Special Meanings

Folder or File Meaning

/App_GlobalResources Contain resource files used for localizing WebForms pages. You’ll

/App_LocalResources learn more about localization in Chapter 15.

/App_Browsers Contains .browser XML files that describe how to identify specific

web browsers, and what such browsers are capable of (e.g.,

whether they support JavaScript).

/App_Themes Contains WebForms “themes” (including .skin files) that influence

how WebForms controls are rendered.

These last few are really part of the core ASP.NET platform, and aren’t necessarily so rele￾vant for ASP.NET MVC applications. For more information about these, consult a dedicated

ASP.NET platform reference.

Naming Conventions

As you will have noticed by now, ASP.NET MVC prefers convention over configuration.

1 This

means, for example, that you don’t have to configure explicit associations between controllers

and their views; you simply follow a certain naming convention and it just works. (To be fair,

there’s still a lot of configuration you’ll end up doing in web.config, but that has more to do

with IIS and the core ASP.NET platform.) Even though the naming conventions have been

mentioned previously, let’s clarify by recapping:

• Controller classes must have names ending with Controller (e.g., ProductsController).

This is hard-coded into DefaultControllerFactory: if you don’t follow the convention, it

won’t recognize your class as being a controller, and won’t route any requests to it. Note

that if you create your own IControllerFactory (described in Chapter 9), you don’t have

to follow this convention.

CHAPTER 7 ■ OVERVIEW OF ASP.NET MVC PROJECTS 207

1. This tactic (and this phrase) is one of the original famous selling points of Ruby on Rails.

10078ch07.qxd 3/26/09 12:24 PM Page 207

• View templates (*.aspx, *.ascx), should go into the folder /Views/controllername.

Don’t include the trailing string Controller here—views for ProductsController should

go into /Views/Products (not /Views/ProductsController).

• The default view for an action method should be named after the action method. For

example, the default view for ProductsController’s List action would go at /Views/

Products/List.aspx. Alternatively, you can specify a view name (e.g., by returning

View("SomeView")), and then the framework will look for /Views/Product/SomeView.aspx.

• When the framework can’t find a view called /Views/Products/Xyz.aspx, it will try

/Views/Products/Xyz.ascx. If that fails, it tries /Views/Shared/Xyz.aspx and then

/Views/Shared/Xyz.ascx. So, you can use /Views/Shared for any views that are shared

across multiple controllers.

All of the conventions having to do with view folders and names can be overridden using

a custom view engine. You’ll see how to do this in Chapter 10.

The Initial Application Skeleton

As you can see from Figure 7-1, newborn ASP.NET MVC projects don’t enter the world empty

handed. Already built in are controllers called HomeController and AccountController, plus a

few associated view templates. Quite a bit of application behavior is already embedded in

these files:

• HomeController can render a Home page and an About page. These pages are generated

using a master page and a soothing blue-themed CSS file.

• AccountController allows visitors to register and log on. This uses Forms Authentica￾tion with cookies to keep track of whether each visitor is logged in, and it uses the core

ASP.NET membership facility to record the list of registered users. The membership

facility will try to create a SQL Server Express file-based database on the fly in your

/App_Data folder the first time anyone tries to register or log in. This will fail if you don’t

have SQL Server Express installed and running.

• AccountController also has actions and views that let registered users change their

passwords. Again, this uses the ASP.NET membership facility.

The initial application skeleton provides a nice introduction to how ASP.NET MVC appli￾cations fit together, and helps people giving demonstrations of the MVC Framework to have

something moderately interesting to show as soon as they create a new project.

However, it’s unlikely that you’ll want to keep the default behaviors unless your applica￾tion really does use the core ASP.NET membership facility (covered in much more detail in

Chapter 15) to record registered users. You might find that you start most new ASP.NET MVC

projects by deleting many of these files, as we did in Chapters 2 and 4.

Debugging MVC Applications and Unit Tests

You can debug an ASP.NET MVC application in exactly the same way you’d debug a traditional

ASP.NET WebForms application. Visual Studio 2008’s debugger is essentially the same as its pre￾vious incarnations, so if you are already comfortable using it, you can skip over this section.

208 CHAPTER 7 ■ OVERVIEW OF ASP.NET MVC PROJECTS

10078ch07.qxd 3/26/09 12:24 PM Page 208

Launching the Visual Studio Debugger

The easiest way to get a debugger going is simply to press F5 in Visual Studio (or go to Debug ➤

Start Debugging). The first time you do this, you’ll be prompted to enable debugging in the

Web.config file, as shown in Figure 7-2.

Figure 7-2.Visual Studio’s prompt to enable debugging of WebForms pages

When you select “Modify the Web.config file to enable debugging,” Visual Studio will

update the <compilation> node of your Web.config file:

<system.web>

<compilation debug="true">

...

</compilation>

</system.web>

This means that your ASPX and ASCX templates will be compiled with debugging sym￾bols enabled. It doesn’t actually affect your ability to debug controller and action code, but

Visual Studio insists on doing it anyway. There’s a separate setting that affects compilation of

your .cs files (e.g., controller and action code) in the Visual Studio GUI itself. This is shown in

Figure 7-3. Make sure it’s set to Debug (Visual Studio won’t prompt you about it).

Figure 7-3. To use the debugger, make sure the project is set to compile in Debug mode.

■Note When deploying to a production web server, you should only deploy code compiled in Release

mode. Similarly, you should set <compilation debug="false"> in your production site’s Web.config file,

too. You’ll learn about the reasons for this in Chapter 14.

CHAPTER 7 ■ OVERVIEW OF ASP.NET MVC PROJECTS 209

10078ch07.qxd 3/26/09 12:24 PM Page 209

Visual Studio will then launch your application with the debugger connected to its built￾in development web server, WebDev.WebServer.exe. All you need to do now is set a breakpoint,

as described shortly (in the “Using the Debugger” section).

Attaching the Debugger to IIS

If, instead of using Visual Studio’s built-in web server, you’ve got your application running

in IIS on your development PC, you can attach the debugger to IIS. In Visual Studio, press

Ctrl+Alt+P (or go to Debug ➤ “Attach to Process”), and find the worker process named

w3wp.exe (for IIS 6 or 7) or aspnet_wp.exe (for IIS 5 or 5.1). This screen is shown in Figure 7-4.

■Note If you can’t find the worker process, perhaps because you’re running IIS 7 or working through a

Remote Desktop connection, you’ll need to check the box labeled “Show processes in all sessions.” Also

make sure that the worker process is really running by opening your application in a web browser (and then

click Refresh back in Visual Studio). On Windows Vista with UAC enabled, you’ll need to run Visual Studio in

elevated mode (it will prompt you about this when you click Attach).

Figure 7-4. Attaching the Visual Studio debugger to the IIS 6/7 worker process

Once you’ve selected the IIS process, click Attach.

Attaching the Debugger to a Test Runner (e.g., NUnit GUI)

If you do a lot of unit testing, you’ll find that you run your code through a test runner, such as

NUnit GUI, just as much as you run it through a web server. When a test is inexplicably failing

(or inexplicably passing), you can attach the debugger to your test runner in exactly the same

way that you’d attach it to IIS. Again, make sure your code is compiled in Debug mode, and

then use the Attach to Process dialog (Ctrl+Alt+P), finding your test runner in the Available

Processes list (see Figure 7-5).

210 CHAPTER 7 ■ OVERVIEW OF ASP.NET MVC PROJECTS

10078ch07.qxd 3/26/09 12:24 PM Page 210

Figure 7-5. Attaching the Visual Studio debugger to NUnit GUI

Notice the Type column showing which processes are running managed code (i.e., .NET

code). You can use this as a quick way to identify which process is hosting your code.

Remote Debugging

If you have IIS on other PCs or servers in your Windows domain, and have the relevant debug￾ging permissions set up, you can enter a computer name or IP address in the Qualifier box and

debug remotely. If you don’t have a Windows domain, you can change the Transport drop￾down to Remote, and then debug across the network (having configured Remote Debugging

Monitor on the target machine to allow it).

Using the Debugger

Once Visual Studio’s debugger is attached to a process, you’ll want to interrupt the application’s

execution so you can see what it’s doing. So, mark some line of your source code as a break￾point by right-clicking a line and choosing Breakpoint ➤ “Insert breakpoint” (or press F9, or

click in the gray area to the left of the line). You’ll see a red circle appear. When the attached

process reaches that line of code, the debugger will halt execution, as shown in Figure 7-6.

Figure 7-6. The debugger hitting a breakpoint

CHAPTER 7 ■ OVERVIEW OF ASP.NET MVC PROJECTS 211

10078ch07.qxd 3/26/09 12:24 PM Page 211