By the Skin of Your App (Cont.)

There's probably nothing here that you haven't seen or done before. In fact, you may be saying, "Get to the point, already." Well, you see, I love this stuff too much to skim through it quickly, so I purposely dwell on the obvious in order to absorb the beauty that is the code. If you run this page you'll see your two textboxes filled with the text that was placed in them in the code-behind page. If you click on the button, the DataGrid will display three rows of data. All this data gets loaded in the code-behind page. Now it gets interesting: let's add another Web Form called MemberList2.aspx. This form will have the same controls as MemberList1.aspx, but this time let's lay them out in a completely different arrangement (Figure 2).

So far so good, right? Two Web Forms with identical controls, only each lays them out differently. Before you start coding the code-behind page on the second Web Form, remember the point of this article is to illustrate a skinning technique that will enable you to have radically different page layouts. As you have probably guessed, this second page will represent our second skin, hence the same controls with a different layout. Since you've already coded the controller for Web Form1.aspx by way of the Web Form1.aspx.cs code-behind class, you don't have to repeat this work. You want to show the same data and provide the same behavior, just make it look different.

When I described the little known secret, I stated that you want to learn to drive more than one Web Form with the same code-behind page, so here's how to set it up. Since you've displayed all files, you should see a MemberList2.aspx.cs file underneath the Web Form in the Solutions Explorer. Double-click MemberList2.aspx to display it in a window pane and switch over to HTML view on the Web Form (it's on the lower-right corner of the Web Form window pane). The first line of the HTML page should look like this:

The two items I want to point out here are the CodeBehind= and the Inherits= arguments. The CodeBehind= argument points at the physical file that contains the code-behind for this page, while the Inherits= argument designates the name of the class the page will use to drive it. Move your cursor up to that line and change the two arguments so the Page directive looks like this:

As you can guess, this is what the Page directive line looks like for the MemberList1.aspx Web Form as well. Switch the Web Form back to Design view and double-click on the button in order to bring up the code-behind class. In the Solutions Explorer you can see that MemberList2.aspx now has two code-behinds listed beneath it: MemberList1.aspx.cs and MemberList2.aspx.cs. MemberList1.aspx.cs has in fact moved from underneath MemberList1.aspx. Next, since you don't need to use MemberList2.aspx.cs, delete it. Right-click on it and choose Delete from the popup-menu. Now if you switch back and forth between the two Web Forms in their Design windows and choose View Code from the Solutions Explorer, you will see the same class (MemberList1.aspx.cs) come up and also switch to display underneath the selected Web Form.

You've now done everything necessary to drive the MemberList2.aspx Web Form with the code-behind that Visual Studio originally exclusively assigned to MemberList1.aspx. See Figure 3 and Figure 4 to see the two member list pages, with their totally different layouts, yet controlled by the same code-behind class. Of course you could have repositioned these controls using style sheets, but imagine both of these pages with a totally different graphical theme behind them. Now you can see how the power in this technique comes into play.

Let's quickly review. You now have two separate Web Forms driven by a single code-behind page. Both Web Forms have the same controls on them, and these controls are defined and addressed in the code-behind page that drives both Web Forms. Each Web Form, though displaying the same controls, displays them in a totally different layout. Indeed, you can add any styling or graphics you want to either of these two views. Each of these two Web Forms represents a different skin for representing the same data. As the programmer, you choose how a particular skin gets chosen for display. You could have this information stored in a database that defines the available skins and which one to assign to a given user. Depending on which user is logged into your system, you can retrieve the appropriate skin name and use it to build complete page names for redirecting purposes.

Getting back to the MVC pattern, I've effectively shown you how to implement multiple Views driven by a single Controller. The Model in this basic example is non-existent, but in a real-life scenario you would probably have a business logic layer of some sort that provides you with the Model you need to power the Controller. It's important to understand that this is one implementation of an MVC design. There are other documented implementations of an MVC pattern where the one-to-many relationship may be on the views-to-controllers (just the opposite of what you are using here). The point is that the pattern separates the Model from the View from the Controller, so in fact you can relate them any way you want. You can even have multiple models driving one controller driving multiple views. Everything depends on your application needs (I'll show you what I mean in a minute). What you need to understand is that every ASPX page needs the exact same Web Server controls on it, since the code-behind uses them.

While style-sheets can definitely provide a great deal of presentation variations, including positioning variation, a good skinning technique may include a lot of different images that could vary from theme to theme. That makes the skinning technique truly shine.

MVC Patterns

For another look at the MVC pattern applied to the presentation tier, read Professional Design Patterns in VB.NET: Building Adaptable Applications from Apress (ISBN: 1-59059-274-3). One of the final chapters in this book shows you a technique for sharing one code-base from Web to Windows applications using an MVC architecture, and in fact illustrates multiple controllers for a single view.