Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Okay, i know there have been some questions about this before, but I just want to know what the situation is now. If I am creating an ASP.NET MVC web app, should I use the built in Membership Provider or roll my own?
I feel that the existing one is perhaps overkill, but then again, it has been tested to death and works very well. I don’t like the millions of table and sprocs it puts in the database, but should I just delete the stuff I don’t need, or just not worry about it and use it anyway?
Whilst you say this is a possible duplicate, I think it’s fair enough to seek clarification on the current situation and you do seem to have considered the possibilities.
I still tend to use the built-in membership provider for the reasons you’ve stated (it just works) and then add my own tables for things like OpenId, Facebook, etc, etc and tie them back to user ids in the aspnet_Users table.
Thus far I tend not to worry about the extraneous stuff it puts in the database.