Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Microsoft ASP.NET 2.0 Membership API Extended : Page 5

Working with big applications requires extending the Microsoft ASP.NET 2.0 Membership API to handle more detailed member records.


advertisement
Test the Extended Membership API
Now that you have developed the ExtendedMemberShipProvider, I'll look at a set of examples on how to use this provider.

Before you can take the next step, you need to configure the newly developed provider in the web.config file of the web application. The Provider Toolkit utility creates the configuration sections needed to add to the web.config file (see Listing 4).

The web.config file configures the current web application to use the new ExtendedMemberShipProvider.

Figure 2. CreateUserWizard: This figure shows the CreateUserWizard with three custom fields.
Now that you have configured the new provider in the web.config file, you can start testing that provider. All the samples that I've presented are part of a web application in the accompanying downloadable code of this article.

The first sample creates a new user as shown in the ASPX page shown in Figure 2. The figure shows the CreateUserWizard that you customized to have three additional fields: FirstName, LastName, and DateOfBirth. By default, the CreateUserWizard calls the CreateUser method in the Membership Provider; however, since I'm using a different provider, I will keep the default behavior of that control the same, and then I can override the event called OnCreatedUser, where I'll add my custom fields to the UserInfo table.

Once the CreateUserWizard finishes adding the member records to the Membership-related tables, ASP.NET raises the OnCreatedUser event to process the custom fields. Listing 5 shows the implementation of that event.

The CreateUserWizard1_CreatedUser method gets the custom-field values from the CreateUserWizard control, checks if ASP.NET actually created the member records in the database, and then adds the detailed information about that member to the UserInfo table. The second sample deletes a user from the database.

Figure 3 shows a drop-down list with all the user names found in the database. When you select a user name, you need to press the Delete button to completely delete the member record and its details from the UserInfo table.

 
Figure 3. Delete User Screen: Here's how the Delete User screen looks in the sample application.
I've implemented the event handler for the Delete button in the following code snippet:

protected void btnDelete_Click(object sender, EventArgs e) { // Get the selected user name: string UserName = this.ddlUserNames.SelectedValue.ToString(); // Delete if (ExtendedMembership.DeleteUser(UserName) == true) { this.lblMsg.Text = "User deleted"; return; } this.lblMsg.Text = "User could not be deleted!"; }

The last sample that I'll discuss is the Update User screen (see Figure 4). The UI displays the member's user name, Bilal, from the drop-down list. Once you select the user name, you need to click the Submit button. After that ASP.NET displays a populated form with the chosen member's information below the drop-down list. You can now edit those fields and click "Update User" to update that user in the database.

Figure 4. Update User Screen: Here's how the Update User screen looks in the sample application.
I've implemented the event handler for the Update User button as shown below:

protected void updatebtn_Click(object sender, EventArgs e) { // Update the user string Email = Server.HtmlEncode(this.Email.Text); DateTime DateOfBirth = Convert.ToDateTime( Server.HtmlEncode(this.PopCalendar1.SelectedDate)); string Comments = Server.HtmlEncode(this.Comment.Text); bool isApproved = this.IsApproved.SelectedValue.Equals( "1")? true : false; // Execute Update MembershipUser _mu = Membership.GetUser( this.ddlUserNames.SelectedValue.ToString()); _mu.Email = Email; _mu.Comment = Comments; _mu.IsApproved = isApproved; try { ExtendMemberShip.Update(new ExtendedMembershipUser( _mu, null, null, DateOfBirth)); this.ErrorMessage.Text = "User record update successfully!"; } catch { this.ErrorMessage.Text = "User record could not be updated!"; } this.Panel2.Visible = false; }

The method above gets the field values from the form, and then calls the ExtendedMembership's Update method to update the default values stored and the ones stored in the UserInfo table.

There are still two methods that I have not mentioned here: ExtendedMembership.GetUser and ExtendedMembership.GetAllUsers. For instance, I used the ExtendedMembership.GetAllUsers method above when I loaded the UserName drop-down list. I used the ExtendedMembership.GetUser method above to retrieve and display all the details of a member record when I selected a user name.

I suggest you look at all the above code samples in the downloadable code accompanying this article.

Advantages and Disadvantages of the Extended Membership API
As mentioned at the beginning of this article, there are two ways to extend the Membership API in ASP.NET 2.0. One extension inherits from the MembershipProvider and thus overrides all the methods that the MembershipProvider provides using custom code to extend the Membership API. I discussed the second extension throughout this article where instead of touching the default Membership API you built upon it—gaining the chance to use both the Extended Membership API and the default one in the same web application.

From a performance point of view, the latter method inherits from MembershipProvider, and then uses other new features in ASP.NET 2.0 to process any customized data. For example, using the first method you will have to override the CreateUser method to add member records to the default Membership API database and to the UserInfo table. In that case, you must save all the custom data from the CreateUserWizard in the Profile object (another new feature in ASP.NET 2.0) in the user-interface layer. The Profile object allows you to process custom data inside the overridden CreateUser method—thus utilizing more than one feature for the sake of extending the Membership API.

In this article I created a provider that works as a wrapper around the default MembershipProvider without touching any of its methods; instead, I used the default methods provided by the Membership provider like CreateUser, DeleteUser, etc.

In the latter method, if you want to use all the available methods in the Membership API, you have to override all the built-in methods that ship with the MembershipProvider; while in the second method, creating the wrapper, you are extending the set of those methods that affect the data collected to a member's record. By extending the set, you get a richer environment to work with; the default Membership API methods are still usable in other places where there is no need to create, update, delete, and get a member's record from a database. For instance, you can still use the ValidateUser method, which is automatically called by the Login control from the default Membership API, since it does nothing but check if the user name and password that the user entered are correct and valid in the default database. This method was not extended by the new provider since it can function well without the need to have any information about the new customized data added. By doing this, you are leaving most of the Membership controls to function normally. However, in the first way of extending the Membership API, you have to override the ValidateUser method if you are going to validate a user and it is something you would normally do!

Finally, the techniques I've discussed in this article give you the chance to use the default Membership API in addition to a set of customized methods through the Extended Membership API. The first method lacks that rich environment and requires more work to implement all built-in methods in the Membership API, if you need to utilize them, and uses the Profile object in ASP.NET 2.0 to accomplish the task.

To wrap things up, I have discussed one of the methods used in ASP.NET 2.0 to extend the Membership API. I've demonstrated extended functionality to the Membership API and left the main Membership API untouched; thus, giving you a richer environment to work with.

In addition to the main focus on extending the Membership API, I have introduced the Provider Toolkit, which you can download for free, to help you build your own provider models and presented a utility that you can use to configure and customize the Provider Toolkit to your needs in a matter of few seconds.

Last but not least, I would like to thank Peter Kellner who inspired me to write this article, Alister Jones who never stops supporting me, to the LebDev.NET user group, and to all my professors and friends. Finally, I would like to dedicate this article to the memory of my late, great friend, Jim Ross, who believed in me and never missed a chance to push me forward.



Bilal Haidar is a graduate from Lebanese American University with a double major in Computer Engineering and Computer Science with distinction in 2004. He has been a Microsoft MVP (ASP/ASP.NET) for two consecutive years, ASP.NET author at ASPAlliance.com, and works as a system developer at Consolidated Contractors Company (CCC). At work, Bilal follows the latest technologies in the field of .NET development; otherwise he spends most of his time reading, researching, and working on his private freelancing projects. Bilal posts tips, tricks, and tutorials on .NET development-related stuff on his blog.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap