I feel it makes sense NOT to use custom membership & role providers
- From: alexandis@xxxxxxxxx
- Date: Wed, 07 Nov 2007 08:54:33 -0800
We have tables of logins (users), that differs much from standard
microsoft structure - we don't use control question/answer, date
fields, etc. But instead we have several additional fields.
I expanded membership class and it works for logging in, but going
further - creating user - I must make following in CreateUserWizard
template:
1) create 'users' record filling standard microsoft fields and ignore
those I don't use (mentioned above), i.e. put nulls, "", mindate,
etc...
2) update this record, initializing it with MY fields
So, one db operation operation is splitted. It looks ugly...
Concerning role provider: they offer user2role with userName and
roleName fields! But in this case I don't have relationship between
tables, because userName is not a primary key in users table (ID is,
but ID is integer).
I've decided to make custom login control and NOT to use custom
membership provider and role provider.
I ~hope~ it's correct decision. But I'd like to hear objections, until
it's too late :) and good article about further process... maybe there
is one from the person who took the same decision. Is there much work
to go without standard login control and provider? Would it be good to
have classes similar to the one I've already made as custom providers?
Maybe I could just change them and adopt for use as NOT provider-
classes?
.
- Follow-Ups:
- RE: I feel it makes sense NOT to use custom membership & role provider
- From: Peter Bromberg [C# MVP]
- RE: I feel it makes sense NOT to use custom membership & role provider
- Prev by Date: Question about VS 2005 and Creating Web Site
- Next by Date: Filling Datagrids based on dropdown
- Previous by thread: Question about VS 2005 and Creating Web Site
- Next by thread: RE: I feel it makes sense NOT to use custom membership & role provider
- Index(es):
Relevant Pages
|
