Is it worth using ASP.NET's membership/role provider model if you're doing a completely homebaked implementation?

Question

I'm working on a website that will be using Facebook Connect to authenticate users. We also have some database structure on the backend to associate users via their Facebook user id to various groups and roles.

In short, the requirements for the project don't really have a lot of crossover with the functionality defined by ASP.NET's membership and roles provider model.

Given that, is there any reason to implement a custom membership provider for this stuff other than it working with the "built-in" stuff and having access to it via the Membership static class?

Answer 1

Yes. It's very easy to implement a MembershipProvider (you really only need to implement the ValidateUser method) and you get access to some very useful asp.net features which at least simplify a lot of your code (I'm thinking of helpers like Page.User).

Answer 2

Only if you want to use built-in or a third-party components based on ASP.NET's Membership model. If not - don't bother with this, as this will limit your application.

Answer 3

The membership APIs are a facade pattern, so you can swap in a different provider when Facebook goes the way of MySpace and is replaced with the next social networking fad.

So you'd implement a custom provider with Facebook as the back and swap it with other things for testing and future proofing.

By completely, how complete is your solution? The membership API's have cool stuff like a password generator, will keep track of who's online (by recency of login).