Friday, June 1, 2007

The Provider Model of ASP.NET 2.0

Introduction

The new version of ASP.NET, i.e., ASP.NET 2.0 offers a wide range of features that are an improvement on its earlier counterpart, ASP.NET 1.x. It has enhanced the support for administration, user and roles management, extensibility, security and performance, to name a few. One of such new features is the ASP.NET 2.0 Provider Model. The provider model defines an easy plug-and-play architecture in Microsoft .NET. This article discusses ASP.NET's new features, like Membership, Personalization, and Profile.
The Provider Model of ASP.NET 2.0

You no longer have to depend on the web.config file (the application’s configuration file) for defining roles in your application. With ASP.NET 2.0 around, you have support for Membership and Role provider classes, like, the SqlMembershipProvider and SqlRoleProvider. However, the only constraint is that these are designed to work with SQL Server only. No worries; you can extend these classes to create your own custom provider implementations with support for any data store. We would learn more on Providers and their types in the sections to follow.
The ASP.NET Provider Model provides a pluggable architecture for working with providers. You can have the flexibility of using the custom providers; you can even implement your own providers in your applications. Well, what is a provider, anyway? The applications need some way of storing states, either in the temporary main memory or in a persistent manner in the database. "A provider is a software module that provides a uniform interface between a service and a data source. Providers abstract physical storage media, in much the same way that device drivers abstract physical hardware devices."
The Membership and the Role Management Providers follow the provider pattern through the usage of an interface for a contract based approach. The base class for all the providers in such a pattern is the ProviderBase abstract class. All the other providers are actually inherited from this ProviderBase abstract class. The MembershipProvider and the RoleProvider classes that inherit the ProviderBase class are also abstract classes. David Hayden says, "the theory of the pattern is that it allows us to define a well-documented, easy-to-understand API, such as our new Whidbey Membership API's, but at the same time give developers complete control over the internals of what occurs when those API's are called."
You can read about it at the following link:
http://aspalliance.com/1293_Introduction_to_ASPNET_20_Provider_Model

Debugging SQL Server 2005 Stored Procedures in Visual Studio

With Microsoft SQL Server 2000 it was possible to debug stored procedures from directly within Query Analyzer (see Debugging a SQL Stored Procedure from inside SQL Server 2000 Query Analyzer for more information). With SQL Server 2005, however, this functionality was moved out of SQL Server Management Studio and into the Visual Studio IDE. Using this technique, it is possible to step into your stored procedures, one statement at a time, from within Visual Studio. It is also possible to set breakpoints within your stored procedures' statements and have these breakpoints hit when debugging your application.
All editions of SQL Server 2005 include debugging support (including the Express Edition). However, only the Team Systems and Professional editions of Visual Studio enable stored procedure debugging from within the IDE. In short, if you are using Visual Web Developer or Visual Studio Standard Edition then you cannot step through a stored procedure or enter the stored procedure via application debugging.

You can read about it at the following link:
http://aspnet.4guysfromrolla.com/articles/051607-1.aspx