Wrox Programmer Forums
|
BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0
This is the forum to discuss the Wrox book ASP.NET 2.0 Website Programming: Problem - Design - Solution by Marco Bellinaso; ISBN: 9780764584640
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old April 8th, 2008, 04:27 PM
Authorized User
 
Join Date: Mar 2007
Posts: 10
Thanks: 0
Thanked 0 Times in 0 Posts
Default ManageUsers

What is the benefit to the private collection in the ManageUsers page?

private MembershipUserCollection allUsers = Membership.GetAllUsers();

Correct me if I am wrong, but any postback will cause a whole new requerying of all the users, right? That seems pretty extreme to me.

Does the membership provider cache that data perhaps?
 
Old April 8th, 2008, 09:27 PM
Lee Dumond's Avatar
Wrox Author
 
Join Date: Jan 2008
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
Default

Not really that extreme, if you're only talking 7 users. ;)

In a real-life scenario, you might consider replacing this with the overload of GetAllUsers(int pageIndex, int pageSize, out int totalRecords) as to limit the number of users that are fetched when populating the grid, and then implement paging in the grid using the same method.

 
Old April 9th, 2008, 03:05 PM
Authorized User
 
Join Date: Mar 2007
Posts: 10
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Well that would take care of the case when you were actually trying to show all users or at least a page of them. (It would mess up the TotalUsers count but I'm not really concerned about that.) It just seemed strange that the reason that the datagrid is initially un-populated is to speed up the rendering of the page, and yet anything we do on the page would require refetching allusers (or a subset of them). And then, if I only want to see users with name starting with "G" then that would cause a postback and a GetAllUsers for the private collection, and then a GetUsersByUserName for the users starting with "G".

I guess I am just surprised, since the rest of the book seems pretty well thought out.
 
Old April 9th, 2008, 05:30 PM
Lee Dumond's Avatar
Wrox Author
 
Join Date: Jan 2008
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
Default

There is actually an alternate way to handle this; and that's to get rid of the private allUsers variable altogether, and call Membership.GetAllUsers() explicitly only as needed.

1. Delete the line that contains the allUsers declaration.

2. In Page_Load, do:
lblTotalUsers.Text = Membership.GetAllUsers().Count.ToString();

This method will now only be called upon the first page load, and the value will be cached in ViewState for subsequent postbacks.

3. In the BindUsers method, get rid of the following:
if (reloadAllUsers)
    allUsers = Membership.GetAllUsers();

And, while you're at it, you can get rid of the parameter in the signature and just have BindUsers(), while of course changing all references to match. The only time this method is ever passed "true" is in the RowDeleting method, and we're now instead going to call GetAllUsers() directly in that method.

4. In gvwUsers_RowDeleting, do this:
lblTotalUsers.Text = Membership.GetAllUsers().Count.ToString();

With the code altered this way, the only time the database is queried (or requeried) for the list of all users is either upon initial page load, or after a delete operation, which is exactly what you want to happen.

Again, for large membership lists, I would combine the above strategy with the paging-enabled overload of GetAllUsers for even better performance.






 
Old April 9th, 2008, 08:45 PM
Lee Dumond's Avatar
Wrox Author
 
Join Date: Jan 2008
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
Default

I should probably also point out that the delete logic is slightly flawed, in that it deletes the user and their profile, but does not delete the user from the UsersInRoles table, not does it delete the user from the PersonalizationPerUser table.

I would suggest the following for "fully" delete a user:

protected void gvwUsers_RowDeleting(object sender, GridViewDeleteEventArgs e)
    {
        string userName = gvwUsers.DataKeys[e.RowIndex].Value.ToString();
        ProfileManager.DeleteProfile(userName);
        if (Roles.GetRolesForUser(userName).Length > 0)
            Roles.RemoveUserFromRoles(userName, Roles.GetRolesForUser(userName));
        PersonalizationAdministration.ResetUserState("~/Default.aspx", userName);
        Membership.DeleteUser(userName);
        BindUsers(true);
        lblTotalUsers.Text = Membership.GetAllUsers().Count.ToString();
    }

 
Old April 10th, 2008, 10:27 AM
Authorized User
 
Join Date: Mar 2007
Posts: 10
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hmmm... interesting. And Thanks! I would have never caught that.

I'm gonna have to take a look at PersonalizationAdministration.ResetUserState and see what that is all about.
 
Old April 10th, 2008, 12:31 PM
Lee Dumond's Avatar
Wrox Author
 
Join Date: Jan 2008
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
Default

Quote:
quote:Originally posted by GameGorilla
 Hmmm... interesting. And Thanks! I would have never caught that.

I'm gonna have to take a look at PersonalizationAdministration.ResetUserState and see what that is all about.
You would actually want to call this for each page that has personalization (which in this site is only the home page).

 
Old April 10th, 2008, 03:29 PM
Authorized User
 
Join Date: Mar 2007
Posts: 10
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Thanks.

I'm really not too happy with the whole membership system. About %50 of my site is businesses managing user accounts (customers and employees). It has been a huge hassle dealing with it all (extending the sqlmembership provider and using the sqltableprofile provider).
 
Old April 10th, 2008, 05:36 PM
Lee Dumond's Avatar
Wrox Author
 
Join Date: Jan 2008
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
Default

Quote:
quote:Originally posted by GameGorilla
 Thanks.

I'm really not too happy with the whole membership system. About %50 of my site is businesses managing user accounts (customers and employees). It has been a huge hassle dealing with it all (extending the sqlmembership provider and using the sqltableprofile provider).
While the BeerHouse membership implementation is very basic, I think the architectural approach behind it is essentially pretty sound.

I've written about this before, but to me, TheBeerHouse should be treated as a guide -- a "demonstration of concept" if you will -- and not a "finished", ready-to-go site. The idea was to show off some of ASP.NET 2.0's new features, and to present an overall general approach of how to apply n-tier principles to an ASP.NET site; and in that I think it succeeds.

I see a lot of people trying to adopt the implementation hook-line-and-sinker as a fait accompli, which in my opinion is a mistake.
 
Old April 11th, 2008, 10:17 AM
Authorized User
 
Join Date: Mar 2007
Posts: 10
Thanks: 0
Thanked 0 Times in 0 Posts
Default

I was complaining more about Microsofts Memebership system in general, not the way TheBeerHouse used it (other than that pesky local variable that started this thread).





Similar Threads
Thread Thread Starter Forum Replies Last Post
mailto: in ManageUsers.aspx spardoe BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 7 August 12th, 2009 10:48 AM
ManageUsers Repeater issue Antilles128 BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 8 March 3rd, 2008 11:47 PM
Ajax in ManageUsers mesdouri BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 3 July 2nd, 2007 08:21 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.