Top 10 Annotations and Remarks about the Wonderful and Powerful New Features in ASP.NET 2.0 : Page 5
This article discusses 10 features of ASP.NET 2.0 from a real-world perspective. It is not a core reference of classes and methods, but a user's guide with suggestions and trade-offs.
by Dino Esposito
Mar 17, 2006
Page 5 of 5
Probably the most-hyped new feature in ASP.NET 2.0, master pages are a rather effective way to build similar-looking pages. A master page is a distinct page with a .master extension that standard .aspx pages can reference. A master page contains the layout of the page made of static parts shared by all derived pages and dynamic regions that each derived page can customize at will.
A page based on a master is radically different from any other ASP.NET page. It looks like a collection of blocks that the ASP.NET runtime will use to fill the holes in the master. As in Listing 1, the master page contains one or more <asp:contentplaceholder> tags for which derived pages (named content pages) will provide content for. Listing 2 shows a sample content page.
A content page contains <asp:content> tags each matching one of the placeholders in the master. The contents of the <asp:content> tag is used to replace the master's placeholder when assembling the final markup for the user. This is the essence of master pages in ASP.NET 2.0. Visual Studio .NET 2005 also does a good job of providing page authors with a preview of the final page merging master and content pages. Some considerations apply to master pages.
True visual inheritance à la Windows Forms is not a goal of ASP.NET 2.0 master pages. The contents of a master page are merged into the content page, and they dynamically produce a new page class that is served to the user upon request. The merge process takes place at compile time and only once. In no way do the contents of the master serve as a base class for the content page. There's no way for the page code file to incorporate functions defined on the master. Likewise, trace and debug options, imported namespaces, languages, and whatever settings you set in the @Master directive are not copied at the page level.
You can set the binding between the master and the content at the page level and also at the application or folder level. Application-level binding means that you link all the pages of an application to the same master. You configure this behavior by setting the Master attribute in the
If the same setting is expressed in a child web.config filea web.config file stored in a site subdirectoryall ASP.NET pages in the folder are bound to a specified master page.
Having masters automatically associated with pages is tempting, but consider the following before you do it. A folder configured to use a given master can't contain standard ASP.NET pages that are not bound to the master. At no time can you add a new page to the folder that is not designed to support that particular master.
Personally, I consider master pages to be a purely visual feature. If you need to derive pages that incorporate and inherit predefined behaviors, master pages are not the right feature. In this case, you're better off building your own hierarchy of page classes through the classic OOP mechanism and code file classes.
#10Data Source Controls
In ASP.NET 2.0, data-bound controls can receive their data in two ways: through an enumerable data source object like in ASP.NET 1.x and through a data source control. A data source control is a server control designed to interact with data-bound controls and hide the complexity of the manual data-binding pattern. A data source control saves the developer from writing binding code explicitly as too often required by ASP.NET 1.x.
Data source components not only provide data to controls, they also support data-bound controls in the execution of other common operations such as insertions, deletions, sorting, and updates. Each data source component wraps a particular data provider-relational databases, XML documents, or custom classes. The support for custom classes means that you can now directly bind your controls to existing classes in your business or data access layer.
Existing data-bound controls such as DataGrid and Repeater don't take full advantage of data source controls. Only ASP.NET 2.0-specific controls such as GridView, FormView, and DetailsView benefit from the true power of data source controls. This is because new controls have a different internal structure specifically designed to deal with data source controls and share with them the complexity of the data-binding pattern.
A data source control represents one or more named views of data, each of which manages a collection of data. The data associated with a data source control is managed through SQL-like operations such as SELECT, INSERT, DELETE, and COUNT, and through capabilities such as sorting and paging. Data source controls come in two flavors-tabular and hierarchical, as in Table 2.
Table 2: Data source controls in ASP.NET 2.0
Represents a connection to a Microsoft Access database. Inherits from the SqlDataSource control and uses the Jet 4.0 OLE DB provider to connect to a MDB database file.
Represents a binding to a custom .NET class that returns data. The class is expected to include methods that behave in a certain way.
Hierarchical provider that represents a binding to any provider that supplies site map information. The default provider supplies site map data through an XML file in the root folder of the application.
Represents a connection to an ADO.NET data provider that returns SQL data, including data sources accessible through OLE DB and ODBC.
Hierarchical provider that represents a binding to XML files and strings with or without schema information.
Note that the SqlDataSource class is not specific to SQL Server. It can connect to any ADO.NET provider that manages relational data. Connection string and the provider name are specified via properties.
Two data source controls are of key importance for ASP.NET 2.0 applications because of their frequent use-SqlDataSource and ObjectDataSource.
SqlDataSource works through SQL commands and stored procedures. It returns data through ADO.NET classesDataSet or data reader. It doesn't provide paging capabilities and relies on the stored procedure or the SQL command text for sorting. The SqlDataSource control supplies built-in capabilities for caching and conflict detection. Caching, in particular, means that the result of the query can be stored in the ASP.NET cache for the specified duration and retrieved from there instead of re-running the query.
ObjectDataSource works through method calls and returns data either through ADO.NET objects or custom collection classes. Paging and sorting are supported only if the underlying classes provide paging and sorting mechanisms. In other words, paging and sorting work if the methods provide parameters to extract only a subset of records sorted in a certain way. Caching is automatically supported only if data is returned via ADO.NET classes.
What's the difference between SqlDataSource and ObjectDataSource and when should you use which?
Using SqlDataSource is inherently simpler and requires much less code to write. To some extent, though, it doesn't provide for the implementation of advanced scenarios where a business layer is required. ObjectDataSource allows data retrieval and update while keeping data access and business logic separate from the user interface. On the other hand, using the ObjectDataSource class doesn't automatically transform your system into a well-designed, effective, n-tier system.
Data source controls are mostly a counterpart to data-bound controls so that the latter can work more intelligently. To really benefit from ObjectDataSource, you must have your DAL already in place. ObjectDataSource doesn't break n-tier systems, nor does it transform existing systems into truly n-tier systems. It greatly benefits, instead, from existing business and data layers. Between the lines, the adoption of ObjectDataSource requires the implementation of common enterprise design patterns for a DAL, such as the Table Data Gateway pattern.
Figure 2: Measuring the impact of SqlDataSource and ObjectDataSource on your code.
Overall, I believe that switching to ObjectDataSource increases the complexity of your code and the amount of code you have to write quite significantly. Using ADO.NET classes gives you free caching and some sorting and paging facilities. All of this has to be manually coded if you opt for custom collections. It's my opinion that the complexity gap is larger between SqlDataSource and ObjectDataSource than between two ObjectDataSource instances using ADO.NET and custom classes. On the other hand, the more you take control of the plumbing, the more you gain in flexibility and maintenance.
ASP.NET 2.0 comes with a full bag of new controls and features. All of these features have been designed and implemented to ease your approach to the new platform and to diminish the amount of code you write. Don't be fooled by jaw-dropping demos scientifically created to leave you enthusiastic about a given feature.
ASP.NET 2.0 doesn't lie about its capabilities; some demos, though, tend to show the best case whereas most developers working on real-world applications should perhaps be more interested in average or worst cases. My goal in this article was to take ten features and discuss them enough so that you'll feel comfortable enough to delve deeper beyond the surface of documentation and demos.
Dino Esposito is a mentor at Solid Quality Mentors where he manages the ASP.NET, workflow, and AJAX courseware. A speaker at many industry events including Microsoft TechEd, Basta, DevWeek, and DevConnections, Dino is the author of two volumes of Programming Microsoft ASP.NET 2.0 Applications, for Microsoft Press. You can find late breaking news at http://weblogs.asp.net/despos.