Hi everyone,

I am still learning membership feature.
It seems to me that the membership.createuser is not useful in real-world applications.
When a user sign up, we ask for some more info, such as company name, country, zip code, etc.
And then we will insert a record into User table for him.
This record contains fields more than just username, password and email.
Besides the personal info I mention aboved, this record might contain some more application-specific field, such as Balance=0.
Also, we usually use UsrID (incremented number) as the key across many tables, instead of the GUID return by membership.createuser.
Now, you may say we can make this happen in several steps:
Step1. Create a new user using membership.createuser
Step2. Retrieve UsrID for the user just created
Step3. Initialize any application-specific data field for this user
But this seems so unnatural and broken down compared to the old way-- don't user membership.createuser at all and just use write my own db code and insert the record once.

Am I understanding right?
Because I am new to this feature, please forgive me if my opinion is wrong.


Thank you.

Henry

I understand your frustration, but the new provider model in v2.0 is a different way of looking at things (only time will tell how successful it will be). Think of the design approach: Membership is supposed to give you authentication semantics and hopefully an implementation as well. What does Balance have to do with authentication? That's a semantic of something else (banking or finance or whatever) and if those sementics leaking into the Membership API then it becomes too polluted with unrelated semantics.

So yes, this is a different approach than how we did things before. But before you used to build it all manually. To achieve resuse in both the backend data store for authentication information as well as reuse in terms of the controls that deal with authentication the provider model has a fine line to walk between feature coverage and being narrow and specific to a particular task. When I fisrt started looking at this I had the same reaction you did. I wasn't sure I liked it, but now thinking about the design goals my sense is that the membership API is fairly successful in trying to achieve their design goals.

Now, for the other infomation, then you can build your own custom classes and storage for that, or you could consider the Profile provider. In either case, if you adopt the Membership provider approach then that's an area where you have less work since the model is there to provide you with a standard implementation. The only data you have to worry about is what's beyond the information necessary for membership.

-Brock

weiwei99:

This will probably be changed in a future version of ASP.Net.

I just tried the createuserwizard. Could someone point out the right direction for me? thanks.

In our current site, we usually use four step user creation, the four steps are :

1, fill info

2, info confirmation(readonly)

3, payment

4, final page.

I am not sure if I can use the createuserwizard to have a four step page like that, I would think I can create wizardstep or templatewizardstep, but I am not sure what are createuser and complete step are, they have some special type. How can I add my own step and still use the createuserwizard? It seems I can create a four steps with wizard. But I think it is better to use the createuserwizard. Any suggestion?

Thanks!

You can always use the regular Wizard control to build your own custom set of steps. For the step where you want to create a user in your system, you can call Membership.CreateUser.

-Brock

 

I just want someone confirm that I can not customize the createuserwizard.

Take a look at this post on my blog.

You can customize the CreateUserWizard (Of course it depends on what kind of customization).

Hello.

The create user control is also a wizard control which already has a custom step defined (the one that you seen when you see the control). Since it's a templated control, you can customize its appearance and even add more steps to it. The only thing you need to be aware is that if you customize the control there are some controls which need to have predefined values (example: the buttons that let you move to the next/previous steps need to have a predefined value applied to the CommandName property; if you customize the create user step the textboxes used to fill info regarding the user must also have a predefined ID). The best way to get these values is to use .Net Reflector and look at the values used on the default templates.