Default Membership and User Profiling vs Custom ones.

Question

Hello,

I was just going through the "AccountController.cs" code (the default one which appears when you create a new ASP.NET MVC project). When I tried to compare it to the one that is proposed in my book, I noticed that the two controllers share the same concepts and implements the same methods (LogOn, LogOff, CreateUser, DeleteUser, ChangePassword, etc.). Now, I'm wondering why someone would want to create an AccountController of his own to replace the default one.

Almost, all the books (even professional ones) do not suggest we should create an AccountController. But, one of them (The Beer House) spend a whole chapter on how to implements just that. I really liked it as was able to see a real professional project's code. But, if it's a stuff for very big big website, I might be better off spending my learning time in other subjects.

My question is this one: For a professional website (not very big big), is it safe to use the default AccountController? Or I need absolutely to create a new one. And (most importantly) why? What are the limitations of the default controller??? Can I provide some enhancement to the default one in case it's just a matter of making it specific to address a need?

Thank you

Answer 1

That's a tough question to answer. You need to enumerate any specific needs, requirements, or general funkiness and compare them to what you already have completed for you. If you wire up the existing and it suits you just fine, there's probably no reason to write something new.

Answer 2

Usually you will need to rewrite or at least make many changes in the default AccountController. For example:

• Default AccountController allows anybody to register (create new account) without any email confirmation or even CAPTCHA.
• Default registration needs only login, email and password. Usually you would like to adjust user profile data to specific application.
• There is no "forgot my password" option
• There is no "Edit profile" option.
• I don't know if it is a good idea to integrate your database schema with autogenerated tables (aspnet_XXX). If you have your own "Users" table in your database schema maybe it is better to write your own MembershipProvider using your own "Users" table.
• Default profile provider stores profile data in not intuitive way (there is no table with one column per profile field).