Should I use ASP.NET's default membership provider system, or roll my own?

A friend and I are currently developing a new social app, the details of which we're keeping under wraps until we're ready to start inviting in testers. However, before we get to that point, there is still a lot of design and development work which needs to be done. One important thing that needs working out is the membership system, as I'll explain.

Back when ASP.NET was being developed, we were still in the Web 1.x days. Back then, people rarely had more than one e-mail address, and sites weren't as social as they are now. So the restriction of one e-mail address per account was no big deal. Fast forward to now, and many people have several e-mail accounts. And as e-mail addresses are a great way to share contact information, a lot of Web 2.0 sites allow their users to provide multiple addresses on their profiles. And that's something we'd like to do for our project.

The question I've been asking myself for the last week has been whether or not to use the MembershipProvider system built in to ASP.NET, or to completely roll my own which would support multiple e-mail addresses for a user account. I know it's possible to build custom providers, but that doesn't really address the shortcoming in the entire provider system — merely a shortcoming in the number of various back-ends for storing user profile data.

There's a third option here, as well, which says that multiple e-mail addresses for a user isn't important enough to worry about, and that I should just force users to stick with a single e-mail address. But I don't like that option at all.

So, any advice?

Reblog this post [with Zemanta]
Posted In