Working with Data in ASP.NET 2.0 - Handling BLL and DALLevel Exceptions
In the Overview of Editing and Deleting Data in the DataList tutorial, we created a DataList that offered simple editing and deleting capabilities. While fully functional, it was hardly userfriendly, as any error that occurred during the editing or deleting process resulted in an unhandled exception. For example, omitting the product’s name or, when editing a product, entering a price value of “Very affordable!”, throws an exception. Since this exception is not caught in code, it bubbles up to the ASP.NET runtime, which then displays the exception’s details in the web page. As we saw in the Handling BLLand DALLevel Exceptions in an ASP.NET Page tutorial, if an exception is raised from the depths of the Business Logic or Data Access Layers, the exception details are returned to the ObjectDataSource and then to the GridView. We saw how to gracefully handle these exceptions by creating Updated or RowUpdated event handlers for the ObjectDataSource or GridView, checking for an exception, and then indicating that the exception was handled.
Read more
Working with Data in ASP.NET 2.0 Displaying Data with the DataList and Repeater Controls
In all of the examples throughout the past 28 tutorials, if we needed to display multiple records from a data source we turned to the GridView control. The GridView renders a row for each record in the data source, displaying the record’s data fields in columns. While the GridView makes it a snap to display, page through, sort, edit, and delete data, its appearance is a bit boxy. Moreover, the markup responsible for the GridView’s structure is fixed - it includes an HTML with a table row () for each record and a table cell () for each field. To provide a greater degree of customization in the appearance and rendered markup when displaying multiple records, ASP.NET 2.0 offers the DataList and Repeater controls (both of which were also available in ASP.NET version 1.x). The DataList and Repeater controls render their content using templates rather than BoundFields, CheckBoxFields, ButtonFields, and so on. Like the GridView, the DataList renders as an HTML , but allows for multiple data source records to be displayed per table row. The Repeater, on the other hand, renders no additional markup than what you explicitly specify, and is an ideal candidate when you need precise control over the markup emitted.
Read more
Working with Data in ASP.NET 2.0 - Using the FormViews Templates
In the last two tutorials we saw how to customize the GridView and DetailsView controls’ outputs using TemplateFields. TemplateFields allow for the contents for a specific field to be highly customized, but in the end both the GridView and DetailsView have a rather boxy, gridlike appearance. For many scenarios such a gridlike layout is ideal, but at times a more fluid, less rigid display is needed. When displaying a single record, such a fluid layout is possible using the FormView control.
Read more
Working with Data in ASP.NET 2.0 - Querying Data with the SqlDataSource Control
All of the tutorials we’ve examined so far have used a tiered architecture consisting of presentation, Business Logic, and Data Access layers. The Data Access Layer (DAL) was crafted in the first tutorial (Creating a Data Access Layer) and the Business Logic Layer in the second (Creating a Business Logic Layer). Starting with the Displaying Data With the ObjectDataSource tutorial, we saw how to use ASP.NET 2.0’s new ObjectDataSource control to declaratively interface with the architecture from the presentation layer. While all of the tutorials so far have used the architecture to work with data, it is also possible to access, insert, update, and delete database data directly from an ASP.NET page, bypassing the architecture. Doing so places the specific database queries and business logic directly in the web page. For sufficiently large or complex applications, designing, implementing, and using a tiered architecture is vitally important for the success, updatability, and maintainability of the application. Developing a robust architecture, however, can be overkill when creating exceedingly simple, oneoff applications.
Read more