A team of MVP authors guides you through the .NET 4 Framework
Written by a group of experienced MVPs, this unparalleled book delves into the intricate—and often daunting—world of .NET 4. Each author draws from a particular area of expertise to provide invaluable information on using the various .NET 4, C# 4, Silverlight 4, and Visual Studio tools in the real world. The authors break down the vast .NET 4 Framework into easily digestible portions to offer you a strong foundation on what makes .NET such a popular and successful framework for building a wide range of solutions.
- Breaks down the .NET 4 Framework into easily understandable sections
- Features more than a dozen MVPs serving as authors, each of whom focuses on a particular area of expertise
- Covers such topics as Windows Presentation Foundation, Silverlight 4, Windows Communication Foundation, ASP.NET performance, the entity framework, and more
- Shares C# tips and tricks and .NET architecture best practices from a team of Microsoft MVPs
Real World .NET 4 and C# is the ultimate resource for discovering and understanding the .NET 4 Framework.
|Product dimensions:||6.60(w) x 5.60(h) x 1.00(d)|
About the Author
Editor Bill Evjen is an acclaimed author and speaker. He is the founder of the St. Louis .NET User Group, the founder and former executive director of the International .NET Association,and the author or coauthor of more than 20 books. He works with Microsoft as a Microsoft Regional Director and is an MVP. He is the CIO for Swank Motion Pictures.
Read an Excerpt
Real World .NET, C#, and SilverlightIndispensible Experiences from 15 MVPs
By Bill Evjen Dominick Baier György Balássy Gill Gleeren David Giard Alex Golesh Kevin Grossnicklaus Caleb Jenkins Jeffrey Juday Vishwas Lele Jeremy Likness Scott Millett Christian Nagel Daron Yondem Christian Weyer
John Wiley & SonsCopyright © 2011 John Wiley & Sons, Ltd
All right reserved.
Chapter OneASP.NET and jQuery
by David Giard
Approximately ten years ago, Microsoft introduced ASP.NET — a framework for building web applications using the new .NET platform. ASP.NET was designed to assist developers to build, deploy, and maintain web pages and websites. ASP.NET integrates with Microsoft Internet Information Server (IIS) and provides developers with a rich set of tools to develop dynamic web applications.
When it was introduced, this framework focused on Web Forms. Web Forms abstracted away many of the low-level complexities of HTML and HTTP, giving developers an experience similar to one used to build Windows Forms. By using Web Forms, developers could quickly create an interactive web page, even if they knew little about the underlying technologies of the web. This development experience was similar to the popular Visual Basic language, so it appealed to developers familiar with that language.
Like its predecessor Active Server Pages (ASP), ASP.NET provides a developer with the ability to build web applications using a combination of code and markup.
Unlike the classic ASP, ASP.NET is built on top of the Common Language Runtime (CLR) and uses the power of .NET. Because of this, ASP.NET can take advantage of CLR benefits, such as automatic garbage collection, a rich set of libraries, and a robust security model.
The latest version of ASP.NET includes enhancements to the ASP.NET Web Forms Framework and an updated version of the new ASP.NET Model-View-Controller (MVC) framework. Visual Studio .NET 2010 is also the first version to ship with jQuery libraries, which enable developers to build rich client-side functionality into their websites.
This chapter focuses on what is new in ASP.NET 4. First, you learn about some of the new features and enhancements of ASP.NET 4 Web Forms. Next, you learn about the ASP.NET MVC framework. Finally, this chapter covers how to effectively use jQuery to enhance your application.
Along the way, a sample application provides guidance on how to implement these new features.
UNDERSTANDING WEB FORMS
The Web Forms Framework was introduced with ASP.NET 1.0. Countless websites have been successfully built and deployed using this platform.
Essentially, the Web Forms Framework was designed to abstract away the complexities of Hypertext Markup Language (HTML) and Hypertext Transfer Protocol (HTTP) to make web development feel more like Visual Basic forms development. Following are characteristics of Web Forms application development:
* The developer is presented with a design surface that looks like a web page.
* Web controls are dragged onto this design surface.
* Properties are set on the page and on the controls.
* Code is written to manipulate the page, controls, and associated data.
Using Visual Studio, developers can quickly build a web application. A rich set of built-in controls and third-party controls adds to this abstraction and helps cut down on many development tasks.
Microsoft introduced a number of enhancements to ASP.NET with version 4. Following are a few of the most important ones:
* Improved handling of View State provides users with greater flexibility over the controls that participate in View State.
* The web.config file has been greatly simplified.
* A new Web Project template provides greater functionality.
* web.config transformations make it easier to deploy to a new environment.
Let's take a look at these in a bit more detail.
By default, the web and its underlying transport protocol (HTTP) are stateless. This means that, by default, each request remembers nothing about any previous request. ASP.NET introduced View State as a way to maintain state between pages in a web application.
View State works by automatically creating an extra, hidden input within an HTML form. To save the state of the submitted fields on a page, ASP.NET encodes View State data into a single string and sets the value of this hidden field to that string. This field is created on the server and sent down to the client with the rest of the web page.
This convenience comes at a price. The encoded data is submitted each time the form is submitted and it is returned to the browser with each response. If you have a lot of data stored in View State, that data can get quite large, slowing down communication between the client and the server. Using a previous version of ASP.NET, a developer could turn View State on or off at the page level, or at the control level. Prior to ASP.NET 4, you basically had three options for enabling View State:
* Turn off View State for the entire page — If you do this, you do not realize any of the benefits of View State.
* Turn on View State for the entire page — If you do this, you may encode and add unneeded items to View State, bloating the payload sent between the server and the browser, slowing your application, and degrading the user experience.
* Turn on View State for the page, and then disable View State for controls that do not need it — This strategy works well if you want View State for almost every control on the page, but not for a few controls. It can be a real pain if you want View State enabled only for a couple controls.
ASP.NET 4 provides two relevant properties to control View State: ViewStateMode and EnableViewState. Only ViewStateMode is new in version 4, but the two properties work together.
EnableViewState has been around since the first version of ASP.NET. It can be set for an entire page, or for a single control, and it can be set to either True or False. EnableViewState does not turn on View State for any controls. Rather, it determines whether View State may be turned on for a control, and for any controls below it in the control containership hierarchy. A control's ViewStateMode turns on or off View State, but only if EnableViewState is True. ViewStateMode can be enabled or disabled explicitly, or by inheriting this property from its parent container.
Setting a Page or Control's View State attribute to False disables View State for that Page/ Control and for any controls contained therein.
In previous versions of ASP.NET, the only way to selectively enable and disable View State on controls was to set EnableViewState="True" on the page, and set nableViewState="False" on the controls for which you did not want to maintain the overhead of passing View State between the client and the server.
You can set ViewStateMode as an attribute of a page or control, or you can set it in code. Following are the allowable values:
* Enabled — Turns on View State for a control.
* Disabled — Turns off View State for a control.
* Inherit — Tells ASP.NET to set the ViewStateMode to that of the control's parent container. This is the default value for a user control.
ViewStateMode is only relevant if EnableViewState is set to True for a control or the control's parent. If EnableViewState is True, ViewStateMode turns View State on or off for a given control. By turning on View State, any data associated with a control is encoded on the server, saved with a hidden input field, and rendered to the client, so it will be submitted the next time the form is submitted.
My recommendation is to set EnableViewState to True on the page and to selectively turn on (set to Enabled) ViewStateMode for the controls that will benefit from it. This minimizes the payload sent between the client and server and prevents you from accidentally adding to this payload as you add new controls to the page. Following is an example of this:
<%@ Page ... EnableViewState="True" ViewStateMode="Disabled" %>
<asp:Label runat="server" Text="Enter UserName:" ID="EnterUserNameLabel" />
<asp:TextBox runat="server" ID="UserName" ViewStateMode="true" />
One of the challenges of application development is migrating configuration files from one environment to another. I typically develop my applications in a Development environment, using a Development database, Development web services, and the files on my own computer. Many of these settings (such as connection strings, file paths, and URLs) are set in the application's web.config file.
At some point, I deploy my application to a Test environment, so that testers can try it out. The Test environment can use different connection strings, URLs, and file paths, so I need to modify the web .config at the time I deploy the application to this environment. This problem presents itself again when I deploy to a Staging environment, a Production environment, and any other environment my organization or customer uses.
ASP.NET 4 provides an elegant way to handle modifying a web.config file as the application is deployed to different environments. Using Transformations, you can create a base web.config file and a separate file for each of your environments. Each environment file contains only those elements that vary from the base configuration.
In earlier versions of ASP.NET, the web.config file tended to become bloated and difficult to manage. Even a newly created empty web project contained a large web.config file.
With ASP.NET 4, much of the default configuration has been moved to the machine.config file, making the web.config much smaller. You can even create an ASP.NET application with no settings in the web.config file. Developers are encouraged to add only those settings specific to the application to which the web.config file applies.
A smaller web.config file makes configuration settings easier to find and to manage.
New ASP.NET Web Forms Templates
Visual Studio 2010 includes a new and improved web template that is designed to get web developers up and running faster. You can find the ASP.NET Web Application template in the New Project dialog under Installed Templates Web, as shown in Figure 1-1. From the Visual Studio menu, select File New Project to open this dialog.
This template creates an application that includes Home and About pages, and pages for managing users and roles. The site uses a default stylesheet and master page, giving it a polished look; but developers can modify these files to meet their needs. The application is ready to run and use as soon as it is created. You can add forms and code to the initial site to suit the specific needs of your application. Figure 1-2 shows the structure of an ASP.NET Web Application project as viewed from Solution Explorer.
The ASP.NET Web Application template provides a good starting point for developers who are new to ASP.NET and want to see a sample implementation, as well as developers who want to quickly get a site up. Figure 1-3 shows the default page of this application.
The ASP.NET Empty Web Application template takes the opposite approach. It contains no pages or code — only a nearly empty web.config file. This template contains only the references required by an ASP.NET website. It is designed to give experienced developers maximum flexibility when building their website. Figure 1-4 shows the structure of an ASP.NET Empty Web Application project as viewed in Solution Explorer.
Developers who want maximum control over their web applications will prefer the ASP.NET Empty Web Application template.
The features discussed thus far allow developers to improve on applications without changing the way they write those applications. However, Microsoft recently released ASP.NET MVC — a set of tools that provide a new way to build web applications.
Strictly speaking, ASP.NET MVC was not introduced with .NET 4. Version 1.0 of ASP.NET MVC (or MVC, as it is referred to here) was an out-of-band release that developers could download for free from Microsoft. Visual Studio 2010 shipped with version 2 of this framework. In 2011, Microsoft released MVC version 3 as another out-of-band release. Version 3 is examined here.
I have built many applications using the ASP.NET Web Forms Framework. I continue to enhance existing websites built with this framework. It has served me well over the years, and many other developers have built countless solid, scalable websites on this framework. However, for new websites built on the .NET platform, I recommend using the newer ASP.NET MVC framework.
The MVC framework has the following advantages:
* MVC encourages a greater separation of concerns among the parts of your application. For example, each new page has no code-behind file by default, which discourages users from mixing business logic with the user interface.
* MVC gives a developer greater control over the HTML and CSS that is output to the client.
* Because MVC encourages greater separation of concerns, it makes it easier to test parts of your application in isolation. In particular, the user interface — a notoriously difficult thing for which to create automated unit tests — is separated from the rest of the application.
In an ASP.NET Web Forms application, a URL typically points to a file on disk. Usually, that file is an ASPX page, and that ASPX page controls what happens next. Typically, the page life cycle executes, firing a series of page events (Load, PreInit Init, Prerender, Render) and runs code associated with each of these events.
In an MVC application, a URL points to a Controller method instead of to a file. A Controller method is a public method in a Controller class. A Controller class is a public, concrete class that implements the IController interface and has a name that ends with Controller. As its name implies, the controller handles all the logic of the request. This may involve accepting input data, applying business logic, retrieving data, deciding which view to render, and sending stateful data (the model) down to the client.
If this sounds complicated, tooling built into the framework can help you quickly create controller classes, controller methods, and views.
Versions of MVC
As of this writing, Microsoft has shipped three versions of the ASP.NET MVC framework. Version 1 shipped out-of-band (that is, between releases of Visual Studio) and was available as a download. Version 2 shipped with Visual Studio 2010. In 2011, Microsoft released version 3 of MVC.
This out-of-band version is available as a download from www.asp.net/mvc/mvc3. The install program (shown in Figure 1-5) has one button, labeled Install. Click this button to begin the installation. If you do not already have a version of Visual Studio installed, it will install Visual Studio Express.
The most noticeable difference between versions 2 and 3 of MVC is the view engine. MVC versions 1 and 2 used a view engine based on Web Forms. Server-side code in the Web Forms view engine is identified by placing it between the <% and %>symbols. (I don't know the names of these symbols, so I refer to them as "Bee-Stings.") By default, MVC version 3 uses the new Razor view engine.
In the Razor view engine, server-side code is identified by preceding it with the @ symbol. MVC figures out from the context when to switch back to client-side code. To me, it seems counter-intuitive that I don't explicitly tell the view engine when server-side code is ending. But I have yet to find an example when Razor did not correctly switch back to client side.
The Pieces of MVC
To better understand the MVC, let's take a closer look at each of the pieces that make up the MVC.
HTTP (and, by association, the World Wide Web) is inherently stateless. Every request from the client to the server is independent of every other request. In other words, when the web server receives a request from a client, the server has no memory of any requests that came before. At least, that's true by default.
Excerpted from Real World .NET, C#, and Silverlight by Bill Evjen Dominick Baier György Balássy Gill Gleeren David Giard Alex Golesh Kevin Grossnicklaus Caleb Jenkins Jeffrey Juday Vishwas Lele Jeremy Likness Scott Millett Christian Nagel Daron Yondem Christian Weyer Copyright © 2011 by John Wiley & Sons, Ltd. Excerpted by permission of John Wiley & Sons. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
CHAPTER 1: ASP.NET AND JQUERY 1
CHAPTER 2: ASP.NET PERFORMANCE 33
CHAPTER 3: ETHICAL HACKING OF ASP.NET 63
CHAPTER 4: HOW TO BUILD A REAL WORLD SILVERLIGHT 5 APPLICATION 101
CHAPTER 5: SILVERLIGHT — THE SILVER LINING FOR LINE-OF-BUSINESS APPLICATIONS 145
CHAPTER 6: TIPS AND TRICKS FOR DESIGNERS AND DEVELOPERS 169
CHAPTER 7: MVVM PATTERNS IN SILVERLIGHT 4 179
CHAPTER 8: WINDOWS PHONE "MANGO" FOR SILVERLIGHT DEVELOPERS 223
CHAPTER 9: PRAGMATIC SERVICES COMMUNICATION WITH WCF 247
CHAPTER 10: SECURING WCF SERVICES USING THE WINDOWS IDENTITY FOUNDATION (WIF) 311
CHAPTER 11: APPLIED .NET TASK PARALLEL LIBRARY 349
CHAPTER 12: THE WF PROGRAMMING LANGUAGE 389
CHAPTER 13: PRACTICAL WPF DATA BINDING 427
CHAPTER 14: DRIVING DEVELOPMENT WITH USER STORIES AND BDD 489
CHAPTER 15: AUTOMATED UNIT TESTING 569
Most Helpful Customer Reviews
This book is a good read. It is comprised of 15 MVP’s and Microsoft Regional Directors. Each author goes over a problem or situation, educates you and offers their own take on how to solve it. Although, there is not a lot of start to finish code in the book, they do offer a download link to download the source code. I skipped around chapters and found that Chapter 3, entitled, “Ethical Hacking of ASP.NET,” is a very good read. The author, Balassy, who has been the Microsoft Regional Director in Hungary since 2005, does a good job explaining what tools are needed, what concepts are needed to learn, and offers solutions to protect oneself from attacks. Balassy puts it best when he states, “You can have a house, a castle, or even a well-protected fortress, but if you build it on a swamp, sooner or later it will go down. That’s a serious risk you have to deal with. You must know the strengths and the weakness of your favorite developer platform, and you must eliminate the threats that the platform brings in your application.” He goes over Session Management, ASP.NET Authentication attacks, and how to protect against certain attacks. Although this book is designed for intermediate to experienced users, beginners will definitely gain from this book as well. Over all, I highly recommend Real World .NET C#, and Silverlight.