SqlMembershipProvider vs custom solutions

Question

I work in a small development team, and there is no consensus on the best approach to a number of key tasks, one of which is membership providers. Now I can’t be sure that this is due to the lack of contact with alternative ways of thinking or with projects of sufficient scale to guarantee a significant investigation.

I have been a .net network developer for several years (and before that php and asp classic), and as a rule, when developing applications, I shy away from using the built-in .net SqlMembershipProvider primarily because it often seems to be much more complicated for my needs , and secondly, because I can only imagine that such a complex data model is likely to lead to a performance hit.

I usually use my own membership and role provider, working on a fairly simple scheme like user -> user roles <- roles . I support the standard membership provider features such as account recovery, profile information, failed account lockout, security questions, etc. Depending on the needs of a related application, for example, a secure AD application, it has several additional functions, a shopping center. It also means that any tasks that arise that require stored processes to process user data are easily recorded and performed very well. Direct SQL commands, good indexing and a simple data model leading to a high-performance, scalable solution that needs to change. I have full control for change as necessary, which I find invaluable.

Based on your experience, would you say this is an outdated approach? Have you ever had scalability issues with your built-in provider? What approach do you usually use and in which scenarios?

thanks

Answer 1

Unless you specifically indicated a compelling reason, I would suggest that you start with SQLMembershipProvider and configure it as needed.

We found that the built-in provider gave us all the basics with virtually no work on our part. There are so many elements to developing a good safety structure, and it's easy to forget one of them, or just be lazy and not use the one “right” way when you ride on your own. Things come to mind such as salty passwords and password reset via email.

Of course, SQLMembershipProvider is not a magic bullet. We had several circumstances when we needed to do something more complicated with authentication. But we were able to resolve them by simply extending the SQLMembershipProvider, rather than replacing it. See My answer to What is a Good Way to Extend .Net Membership to Track User Logins for more details.

We did not notice any significant performance issues arising from SQLMembershipProvider, so I think that playing on the performance map is unfounded. After all, how much time do your users usually spend logging into your system? If all your pages load quickly, there is no real excuse for writing all your own code under the (possibly erroneous) idea that you will improve performance. This is the fear of “premature optimization,” which we continue to read about.

The Roles structure was too simplified for our needs, so we don’t use it at all. But this also does not interfere.

And, as Hogan points out, you will most likely find developers who are already familiar with how the built-in provider works, which means that they will spend less time trying to understand your architecture and (hopefully) more time to do the real work.

Answer 2

Using built-in providers should be easier to maintain and find resources familiar with api (when hiring programmers).