Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Oct 30, 2011 08:31 PM by HeartattacK
Oct 30, 2011 07:52 PM|LINK
Not strictly a MVC question, but here goes anyhow (my UI is an MVC app, though not really relevant)
Using the default aspnet membership provider (that come with a default mvc app)
I got domain objects like Product, Category, etc with members like CreatedBy and UpdatedBy, which will be the UserId of the user created / updated it.
What should the type of this member be (both database and domain class)?
string (c#) and nvarchar(50) seems to be the logical choice but not sure.
Another option would be to create a User object / table to which I add a User record when the user register, so my CreatedBy for instance can be an int (Id of the User record).
Any advice? Kind of brain dead (it's a hobby project)
Oct 30, 2011 08:05 PM|LINK
If you use the default membership provier (without any change) the Users table will be in the membership database (by default it is in the app_data folder and gets attached to the sql express instance). So I'll advise running the aspnet_regsql tool to create
the membership tables in your database (make sure you change the connection string also).
If you use the UserId from the Users table it will be a uniqueidentifier (GUID in c#)
Oct 30, 2011 08:08 PM|LINK
The default's a guid for the asp.net membership provider. I'd consider having a mapping layer between asp.net membership ids and your application's ids simply because of the fact that the membership provider's pretty crap and should you choose to move away
from it (or need windows auth or federated auth) if you rely on that particular implementation, you'd have dug yourself into a hole.
Oct 30, 2011 08:12 PM|LINK
Yep, exactly what it feels like : Digging myself a hole. This default provider kind of force you to do things a certain way also it seems (Like having usernames....I want user's to log in with their email. Easy enough to pass in email address as username,
but that feels just wrong)
So might go completely the other way and implement my own membership provider (was reading on that
here when you replied actually).
Oct 30, 2011 08:16 PM|LINK
You could do that, or you could write an interface with the bits you actually need and then write a wrapper around the default implementation that implements that interface. That way, you're protected. Just make sure your abstraction doesn't use any class
that ties it to asp.net membership. If you write your own provider, you're still tied to that pile of **** (IMO, one of the worst bits of ASP.NET that violates pretty much every design principle out there).
Oct 30, 2011 08:26 PM|LINK
I think I get what you mean. but also not sure (pretty sure I've done something similiar before, but with all the jumping around between technologies I forgot.
So I still have the aspnet membership database objects, and I create my own "linked" storage for users.
My interface declare whatever I need (logon, logoff, register, etc) and the implementation uses the default membership provider plus writing / reading to my own tables and taking in/ returning my own domain objects.
Not sure that's what you meant, since it's still using the default membership provider (the nice part being I can throw it away later when I got more time to dig into this topic, without affecting code that uses it)
You don't perhaps have some links describing the way you suggested?
Oct 30, 2011 08:31 PM|LINK
Don't have links...but what I mean is that you WON'T be using ANY asp.net membership classes in the declaration of your interface. It will be completely agnostic to ASP.NET. Your implementation of that interface can use whatever class makes it easy. This
will mean you won't get nasty surprises if you choose to change your auth. tech.