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)
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#)
Please click 'Mark as Answer' if my reply has assisted you
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.
"If I can see further than anyone else, it is only because I am standing on the shoulders of giants."blog: www.heartysoft.com twitter: @ashic
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).
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).
"If I can see further than anyone else, it is only because I am standing on the shoulders of giants."blog: www.heartysoft.com twitter: @ashic
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?
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.
"If I can see further than anyone else, it is only because I am standing on the shoulders of giants."blog: www.heartysoft.com twitter: @ashic
krokonoster
Contributor
4291 Points
1352 Posts
User Id data type
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)
raduenuca
All-Star
24675 Points
4250 Posts
Re: User Id data type
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#)
Radu Enuca | Blog
HeartattacK
All-Star
55262 Points
5917 Posts
Moderator
MVP
Re: User Id data type
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.
blog: www.heartysoft.com
twitter: @ashic
krokonoster
Contributor
4291 Points
1352 Posts
Re: User Id data type
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).
HeartattacK
All-Star
55262 Points
5917 Posts
Moderator
MVP
Re: User Id data type
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).
blog: www.heartysoft.com
twitter: @ashic
krokonoster
Contributor
4291 Points
1352 Posts
Re: User Id data type
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?
HeartattacK
All-Star
55262 Points
5917 Posts
Moderator
MVP
Re: User Id data type
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.
blog: www.heartysoft.com
twitter: @ashic