Re: I feel it makes sense NOT to use custom membership & role provider
- From: alexandis@xxxxxxxxx
- Date: Fri, 09 Nov 2007 05:30:18 -0800
Writing custom provider from scratch is not a trivia, so I'd like to
show my thoughts, maybe I'm wrong somewhere?
Let's say, we have 'users' table, that contains obligatory fields not
represented in 'microsoft users table'.
Splitting such info into 2 tables (1:1) won't go, because it's
impossible (as far as i can see) to implement transaction for filling
these 2 tables ('CreateUser' method call is hidden) and all in all -
such structure looks clumsy...
Maybe theoretically it's possible to create additional corresponding
fields in custom membership provider class and initialize them in
'CreatingUser' method, then take them for inserting new record in
'CreateUser'? But such approach also looks ugly... :(
Creating own membership provider from scratch is a headache,
especially for beginners (you have to deal with multithreading,
preventing access to membership while initialize method works).
I wonder why Microsoft just hadn't created one more abstraction layer
for the structure of 'users' table? So instead of having
'CreateUser(param1, param2, ... paramN)' we could have something like
'CreateUser(UserStruct user)'....
.
- Follow-Ups:
- References:
- I feel it makes sense NOT to use custom membership & role providers
- From: alexandis
- RE: I feel it makes sense NOT to use custom membership & role provider
- From: Peter Bromberg [C# MVP]
- I feel it makes sense NOT to use custom membership & role providers
- Prev by Date: Embedding video chat?
- Next by Date: Re: I feel it makes sense NOT to use custom membership & role provider
- Previous by thread: RE: I feel it makes sense NOT to use custom membership & role provider
- Next by thread: Re: I feel it makes sense NOT to use custom membership & role provider
- Index(es):
Relevant Pages
|
