ASP.net Profiles and Membership - Custom Providers or should completely I roll my own?

Question

first off, I know that this question could be borderline-duplicate to this one, and yes, it is a bit ironic that I am asking a question for something that I even answered myself.

Now, I am talking about ASP.net Profiles. I am building an application using MVC if that matters, and I believe that the built-in Profile Provider is useless.

So at the moment, I am asking myself: Should I follow my own advice and write a Custom Profile Provider, or should I completely roll my own Profile stuff?

Some assumptions:

• I want my data in a database structure that I decide
• It's a brand new application, no legacy database structure or userbase that needs to be integrated
• Small to Mid-Sized amount of users (max. ~5000 users)
• ASP.net MVC, most likely Silverlight 2 and maybe even some Windows Azure, but I am still experimenting with it, but definitely .net 3.5 SP1.
• And, possibly as the main decision point: Not neccessarily using Forms Auth, the application may eventually use Active Directory or OpenID for Authentication

I still need to investigate if I can use ASP.net Membership with non-standard authentication providers (OpenID), because I think that ASP.net Profiles only make sense when I use ASP.net Membership, so I might eventually end up writing both a custom Membership Provider for OpenID (That essentially just serves as a bridge), and a custom Profile Provider.

So yeah, I think that that might be a good way because I continue to use what the framework already gives me, but I have next to no experience with Membership and Profiles, so maybe someone here has some insight whether or not I should completely roll my own Authentication and/or Profiles, or if I am better off writing custom Membership and Profile Providers, which apparently is what SO did?

Answer 1

I'm not experienced writing my own profile provider, but I have written my own membership provider. It's relatively easy (there are plenty of methods that you don't need to implement). In fact the only methods that seem really required are the GetUser() and ValidateUser() methods.

The only part that's a little tricky (and worth profiling) is that it seems that GetUser() gets called pretty frequently and you should think about caching the results so that you're not always hitting the database.

Answer 2

To be able to answer the question of what to do, you need to sit down and firgure out exactly what all the features and requirements your authentication and profile model requires and then look at what the built in .net stuff offers. Only once you have a list of requirements will you be able to accurately evaluate whether or not yuo'll be best off rolling your own or using the built in providers.

What might be a better line of questioning for you is to say "I need to do x,y and z with my membership and profile providers, what is my best bet?"