ASP.NET 2.0 Instant Results

Wrox Survey Engine

In the text box at the top of the screen, you can enter in a name for your new survey. This example new survey is titled “Are you Addicted to Email?” Once you enter the title of your choice, click Next to continue. You are brought to the screen in Figure 4-8, the next step in the wizard.

Figure 4-8

Figure 4-8 displays a multi-line text box used to store lengthy descriptions about the survey, which are displayed beneath the name of the survey to the user. Once the description has been entered, click Next to go to the Add Questions page, as displayed in Figure 4-9.

You can enter one question and its correlating answers at a time, clicking the Save Question button to save them to the database. After the questions have been entered, click Next, and know that the survey and its questions are now completely entered into the database. This final page of the New Survey is shown in Figure 4-10.

In addition to creating new surveys, you also have the ability to edit existing surveys.

107

Chapter 4

Figure 4-9

Figure 4-10

108

Wrox Survey Engine

Editing an Existing Survey

If you want to edit an existing survey, you can do so by returning to the Administrator page by clicking the Admin link in the menu bar. Then, click one of the Questions survey row-links. This link loads a page used to manage the existing questions for an existing survey, depicted in Figure 4-11.

Figure 4-11 displays each of the questions within a given survey, with clickable hyperlinks in each row provided in order to add, edit, or delete questions for any survey.

So the basic usage of the Survey Engine is summarized as a way of creating and displaying a survey from the web site, and providing management tools to monitor and control the survey as it is responded to.

The next section provides insight to the technically challenging portions of the application and how they all fit together to form the solution. You learn how the classes are modeled and where the important design elements reside.

Figure 4-11

109

Chapter 4

Wrox Sur vey Engine Design

This section provides a detailed look at the inner workings of the web site application, focusing on the classes involved and the integration of data-bound controls to their object connections and SQL Server data connections.

The design of the Wrox Survey Engine is an object-oriented and logically tiered approach, using a limited amount of logical abstraction between the client, business, and data layers of the application. This allows for a developer to conceptualize how the application could be separated into multiple projects, spanning servers and/or locations. This section also explains in detail the two approaches used to bind data to form elements: the SQL Server DataSource and the ObjectDataSource controls.

This topic, as well as other areas of the architecture, is expounded upon later within this section.

Object Binding and SQL Server Data Binding

In an effort to develop an application rapidly and efficiently, there is always a tradeoff for developers to consider. Some project planning and design sessions may point toward the use of faster and lightweight GUI controls to perform the bulk of the work for the developer, saving countless hours of effort. A specific example of lightweight GUI controls would be the GridView and DataList controls. These allow you to drag and drop controls to a WebForm, set some properties in Design View, and run the application. Without writing one line of VB .NET or C# code, you can configure a data source and data-bound control to render completely on the WebForm. The new ASP.NET 2.0 control creates the ADO.NET Connection, Command, Dataset, or DataReader objects for you, providing everything you need to bind to the data at run time. It also properly handles the events used for data binding on the page — something that ASP.NET 1.1 did not do for you (Phew! Thank goodness!). These are in fact a great set of features to take advantage of. But even so, many programmers will read through this book to learn the more extensive and far-reaching features of ASP.NET 2.0, moving on as programmers in the new and improved .NET universe, and rightly so. But for those who are interested in larger-scale deployments with ASP.NET 2.0, it is a worthwhile effort to identify the reasons why the tradeoffs of using more scalable architectures, and what you are losing or gaining with each methodology in ASP.NET 2.0 specifically. The scalability of an architecture has a lot to do with the load it can carry in cases where a large volume of data is involved, or a heavy amount of processing is required. It also refers to the level of control that exists in throttling or directing the processing, traffic, or data appropriately. ASP.NET 2.0 handles such cases with several intrinsic benefits that set it apart as a world class platform for development.

Truly decoupled architectures in the industry are more often seen in larger corporate application development cycles and are usually designed as more generic and pattern-based. The decoupled approach tends to isolate user, business, and data layers of an application into specific sections, allowing each to function independently. This is the nature of distributed development, and has evolved into what is sometimes referred to as composite applications. The distributed design would tend to only provide database execution logic within a layer of code (classes) that are specifically positioned and designed to make such data calls. Only those classes are able to extract and handle data out of the database, acting as a go-between for the other application modules or classes. As such, the use of business objects (such as the Survey class) would allow a request for data to go out to other classes as a data layer (for example, the SurveyDB class), returning data back to the client and binding to the data grid, list box, and so on. This approach is generally acceptable for most applications.

110

Wrox Survey Engine

In this area of object and data binding, you will notice in this Wrox Survey Engine application we make use of the built-in ASP.NET ObjectDataSource controls to bind data from business objects to GUI (graphical user interface) controls. This in many ways mimics a decoupled, object-based approach that has been held as a best practice in recent years, but by itself may not provide all of the custom and robust features that a corporate project’s requirements or design may mandate. Some class objects need to be serialized and transferred through an Internet connection between tiers, in order to allow for the separate server environments. Other class objects or modules are pooled and managed closely using process instrumentation (WMI) or ASP.NET performance monitors (PerfMon). These additional objectlevel requirements can be met using the ObjectDataSource controls, but it may require additional development and is worthy of mentioning in the course of this book.

In addition to the ObjectDataSource controls, the Wrox Survey Engine also uses the SQL Server DataSource controls to extract data from the SQL Server Express 2005 database files and bind it to the GUI controls. Contrary to this line of thinking, the SqlDataSource controls are typically designed as a quick and dirty way to select records from a database and bind them to a form. This process actually includes the SQL statements in the markup of your ASPX files. In direct opposition to a safer and more

distributed approach of the decoupled tiers, this poses a risk to the application and management thereof. As more users access such pages, more database connections may be created (depending on the connection strings used), thereby increasing the number of pooled or non-pooled connections to the database on the server. This can ultimately cause a loss of scalability, and speed, and if not used carefully could pose a risk to sites with heavy traffic. The use of the SqlDataSource controls also requires updates to the source ASPX files of your site whenever database changes are made that affect your queries or stored procedures. This is not ideal for an application to maintain a predictable and manageable state. But as stated in other chapters, and expounded herein, such risks are overlooked, instead providing a meaningful experience with both the ObjectDataSource and the SqlDataSource controls.

Structure of the Site

The site has been structured in an organized fashion, with files contained within folders that make sense for maintaining the code in the most efficient manner. The Controls folder houses all of the user controls, and the ContentFiles folder contains the main ASPX WebForm files of the web site.

The different folder sections of the web application are listed in the following table:

Folder	Description
App_Code	Houses the business layer class (survey.vb) and the data layer class
	(surveyDB.vb).
App_Data	The standard .NET folder for database files.
App_Themes	The themes folder, containing two themes for use with the site.
ContentFiles	The standard ASPX WebForm files for displaying content.
Controls	Stores all user controls.
Images	Stores images for the header or any other pages.
Management	Stores the secured administrative WebForm pages.
Miscellaneous files	These include the Login page, the Web.config file, the sitemap file, and the
	master page file at the root of the site.

111

Chapter 4

Figure 4-12 is a developer’s view of the project’s folders and files from within the Solution Explorer.

Figure 4-12

The next section explains the main database entities involved and how the various survey concepts are implemented within the database.

Data Model and Database Objects

The data model is very simple in nature, being comprised of essentially three basic data elements:

Surveys

Questions

Responses

Each survey has questions, for which you or any web user can provide their own selections, which generates the response values. As such, Figure 4-13 displays a diagram of the database tables involved.

Figure 4-13

Detailed explanations of each of the three tables appear in the subsequent sections.

112

Wrox Survey Engine

The following table describes the contents of the Question table:

Field Name	Data Type	Description
ID	Int	The unique identifier for this record.
SurveyID	Int	The survey to which this question belongs.
Text	varchar(1000)	The actual question text.
OptionA	varchar(1000)	The first of four choices.
OptionB	varchar(1000)	The second of four choices.
OptionC	varchar(1000)	The third of four choices.
OptionD	varchar(1000)	The fourth of four choices.

The next table outlines the Survey table:

Field Name	Data Type	Description
ID	Int	The unique identifier for this record.
Name	varchar(200)	The name given to the survey.
Description	varchar(1000)	The text description given to the survey.
Date	Datetime	The date and time stamp at the time that the survey
		was created.
IsCurrentSurvey	Char(1)	The 0 or 1 value indicating that the survey is the one
		used within the web site as the currently displayed
		survey. 1 represents that the record is the current
		survey, and 0 signifies the record is not the current
		survey.

The following table details the contents of the Response table:

Field Name	Data Type	Description
ID	Int	The unique identifier for this record.
QuestionID	Int	The question ID to which this response applies.
Selection	Char(1)	The A, B, C, or D value corresponding to the user’s
		selection for the question being responded to.

In addition to these three tables, a number of stored procedures are in use. They follow a consistent naming pattern with the other chapters, as shown here:

113

Chapter 4

sprocTableNameSelectList

sprocTableNameSelectSingleItem

sprocTableNameInsertUpdateItem

In such fashion, the following stored procedures are used in the application:

sprocQuestionDeleteSingleItem

sprocQuestionInsertUpdateItem

sprocQuestionSelectList

sprocResponseInsertItem

sprocSurveyInsertUpdateItem

sprocSurveySaveSingleItemAsCurrent

sprocSurveySelectList

sprocSurveySelectSingleItem

sprocSurveySelectSingleItemWhereCurrent

As you can see, the naming convention allows you to easily and quickly find the stored procedures that apply to a specific table, and whether they are selects, inserts, updates, or deletes.

Several noteworthy stored procedures should be reviewed. The first procedure selects a single survey record from the database to display in the CurrentSurvey user control on the Default.aspx homepage:

ALTER PROCEDURE dbo.sprocSurveySelectSingleItemWhereCurrent /*’===============================================================

‘	NAME:	sprocSurveySelectSingleItemWhereCurrent
‘	DATE CREATED:	October 5, 2005
‘	CREATED BY:	Shawn Livermore (shawnlivermore.blogspot.com)
‘	CREATED FOR:	ASP.NET	2.0	- Instant Results
‘	FUNCTION:	Returns	the	‘current’ survey from the database.

‘===============================================================

*/ as

select top 1 * from Survey where iscurrentsurvey = 1

As you can see, the level of complexity within these stored procedures is down to a minimum in this project. The simple table structure of the application is partly the reason for the ease of use and low level of design complexity.

The next procedure is used to select out all of the questions for a given survey ID:

ALTER PROCEDURE dbo.sprocQuestionSelectList /*’===============================================================

‘	NAME:	sprocQuestionSelectList
‘	DATE CREATED:	October 5, 2005
‘	CREATED BY:	Shawn Livermore (shawnlivermore.blogspot.com)

114

		Wrox Survey Engine
‘	CREATED FOR:	ASP.NET 2.0 - Instant Results
‘	FUNCTION:	retrieves all questions and options for a
‘		specific survey from the database.

‘===============================================================

*/

(@id int)

as

SELECT Question.SurveyID, Question.Text, Question.OptionB, Question.OptionA, Question.OptionD, Question.OptionC, Question.ID

FROM Survey INNER JOIN Question ON Survey.ID = Question.SurveyID WHERE (Survey.ID = @id)

These are the basic stored procedures used as examples, but entirely common for these types of applications.

In addition to stored procedures and tables, the Wrox Survey Engine also employs the use of views to provide visibility to somewhat complex queries used to display the percentage results of a survey’s questions. These views are as follows:

viewAnswerPercentByQuestion

viewAnswerSumByQuestion

viewNumberResponsesBySurvey

viewQuestionCountBySurvey

viewResponseCountBySurvey

These are used in conjunction with one another as dependencies, where one view uses or points to the fields of another view. The end result of the views is the viewAnswerPercentByQuestion, which is used by the SurveyResults user control.

Themes and Skins

The project provides a simple way in which to apply themes and skins to each page of the site, without modifying any HTML markup sections on any page (even the master page is safe from special controlbased HTML markup). You can apply a theme to the entire web site by modifying the Web.config file to point to the name of your theme (assuming the theme exists in your project under the App_Themes folder). This is carried out within each ASP.NET form by using the following code in each of the form’s pre-initialization events:

Protected Sub Page_PreInit(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.PreInit

‘this preinit event fires to initialize the page

‘it allows for the theme and title to be set for this page, ‘which actually pulls from the web.config setting

‘via the shared Config class’s exposed properties. Page.Theme = Config.CurrentTheme

Page.Title = Config.PageTitle End Sub

115

Chapter 4

This code accesses the config class’s properties (pulled from the Web.config file), and sets the page’s theme member to be the current theme value. In this way, you can maintain a consistent experience throughout the web site, with only one change needed to the Web.config in order to change the look and feel of the entire user experience! You are probably glad to hear that — I know I am. The exact place where you would change the theme for the site is in the appSettings section of the Web.config, as displayed here:

<!--

<add key=”CurrentTheme” value=”CleanBlue” />

-->

<add key=”CurrentTheme” value=”CleanRed” />

This code displays one of the theme entries as commented out, and one of them as active. Simply swap the two values in order to make the change.

Security Model

The project uses ASP.NET 2.0 Forms Authentication with a SQL Server Security Provider. The initial designation to use this provider from within the ASP.NET Security Administration tool generates a new security database, which is included in the project and used to house all of the user account information and security settings. This security model implements Forms Authentication intrinsically within the various new ASP.NET 2.0 security controls, such as those used to log in, display login status, recover your password, change your password, and create a new user.

The security model mentioned is utilized and referenced in several areas of the application. One such area is in reference to the Management folder of the site. The security model allows you to log in to the web site, and become an authenticated user. The login.aspx form is loaded automatically whenever you try to access any of the ASPX files in the Management folder without first being unauthenticated. This is a clear glimpse at the new ASP.NET 2.0 security model implemented via the Role and Membership Providers. The configuration is such that the only provision to implement such security is an instance of the ASP.NET Login control, such as the following example:

<asp:Login ID=”Login1” runat=”server” />

As a practical use, this provides a clear example of a secure web site folder and the use of role-based access to pages within that folder via the ASP.NET 2.0 Configuration Tool. This tool is essentially used simply for security-rights management. The ASP.NET 2.0 Configuration Tool can be accessed within Visual Studio by clicking Website ASP.Net Configuration from the menu. Once the tool fully loads you’ll see a Security tab. Clicking the Security tab enables you to modify the settings of any folder within your site to allow or restrict access based on roles that you can define and assign users to. The output of this effort generates the Web.config file that lies within the folder that you specified to restrict access to. The following is an example of this Web.config file output:

<?xml version=”1.0” encoding=”utf-8”?>

<configuration xmlns=”http://schemas.microsoft.com/.NetConfiguration/v2.0”> <system.web>

<authorization>

<deny users=”?” /> <allow roles=”Admin” />

<allow roles=”SuperAdmin” />

116