I have been doing some research about how to do custom profileprovider in .NET MVC. It seems pretty complicated. Is there any other alternative? And this is my major concern, why do ppl bother using customer profileprovider? If they want extra information about a user, why don't they just make another table with OneToOne relationship with aspnet_Users with userId or userName as the foreign key?
Please clarify. I'm trying to implement user profile functionality, but I don't wanna go down the wrong path.
Thanks DG
(I am not sure if this helps talk about custom profile providers.. unless I'm misunderstood...)
IMO, what ever you do .. avoid (the baked in) ASP.NET Membership at any cost! It's so over engineered, you'll want to stab yourself in the eye with a blunt spoon :(
Trust me, avoid it.
Why: Should I use the built-in membership provider for an ASP .NET MVC application?
So .. what can we do instead?
It's just so simple to roll your own Username/Password and leverage the built in Forms Authentication. For myself, I'm not a fan of storing -any- passwords in my own database .. so I prefer to use Facebook, Twitter or OAuth as my mechanism for authentication .. which then means I finish up with a simple, basic, custom user class.
I also create my own custom IPrincipal and IIdentity because I want to store a bit more info in the cookie, which Forms Auth creates when a person has been authenticated. This then helps keep my code in my Controllers cleaner and way simpler.
For example, I store the userId of the authenticated person in an encrypted cookie. (the default option is to only store a Name). I also store one or two more things .. but you get the idea. This way, I don't always have the hit the DB to retrieve any user data OR store this crap in a session.
With a roll your own, you can create extra meta data .. and have that extra profile data. Same table? extra table? Who cares ... that's a decision to make way later (and EASY to solve). Get your model right, IMO :) Then once you've locked down your model, you now know what's required and what's optional .. and you can make some DB decisions then.
IPrincipal and IIdentity to really rock your world.