ASP.NET Membership Provider Fails
I’ve been working on a few personal projects. One of them involved building an ASP.NET website. Being the good geek that I am, I thought I’d try out ASP.NET 3.5 and try using things I’ve never used before. That, unfortunately, proved to be my downfall. One of the new features I decided to implement was the ASP.NET membership provider.
From the articles I read, the membership provider seemed to take a lot of the grunt-work out of the mundane tasks such as creating users, handling roles, etc. No one ever told me what a chore it would be to extend, though. One glaring oversight on the part of the default membership provider was that there was no way to do a logical delete on a user. Sure, you can use some fields such as IsApproved or IsLockedOut but that’s really a workaround and not a true solution. There are so many instances where you want to “delete” a user while maintaining all the related records and that’s not possible unless you do a logical delete. This is one big failure in the Membership Provider.
Other gripes I’ve had with the technology are that extending the provider is an extremely painful process and requires an almost complete rewrite of the backend functions. In the end, I’m not saving any time by using this at all. In fact, it’s causing me more grief! I’m also tied to the default database layout for the membership provider. I do not want to use Profiles for storing user information. It’s totally meaningless as I lose the strong typing.
My conclusion… ASP.NET Membership Provider Fails!!! I am seldom so critical of any technology but the ASP.NET team who came up with this really should have a good hard look at what they’ve done, or rather what they failed to do. After spending many hours trying to shoe-horn the membership provider into my solution, I’ve decided to bite the bullet and just implement my own data structures and business logic.
Filed under: Team Foundation Server | 1 Comment
Alvin Yong's Techno Blog 
I totally agree. I wanted to use that for my MessageBase code, but it was such a big pain (It could have been done, but just not worth the effort – Like you said, I wasn’t saving any time by using it.) that I gave up and wrote my own code to handle user accounts and roles.
I think it’s more fun that way too, most application blocks force you into someone else’s mode of thought. I like my code designed the way I think.
Dunno if it’s better, but it makes a lot more sense to me when I dig into it months later.