I trust you'll let me know when you're in the mood for articulating the
reasons why an integer might be a problem for what I'm doing.
This debate rages on, debated by people much smarter than me. This seems
like a "fair" link to start with (be sure to click the links inside the
page, as the page itself doesn't supply too much info). Google for more.
http://www.codinghorror.com/blog/archives/000817.html
For me, the determining factor is that Guids can be created by the
application, which let's me set up all keys (both primary and foreign)
inside the application then push it all to the database in a single
transaction. I'm sure there are techniques to accomplish this with
auto-incs, but with Guids I don't need "techniques" - it's trivial.
Basically, I have three types of users (roles). I need to store some basic
information for each user, plus additional information that has different
fields depending on the user's role. So I'll need the primary table with
three additional tables, which store role-specific information.
So create your "user" table and put a foreign key to the aspnet_Users table
on "UserId". Create your role-specific tables with foreign keys to your
"user" table.
If I create my own provider, I should be able to create relationships
between the specialized tables and the basic information table. This
should allow the database to enforce the relationship so that I could
never delete user information in the basic table without also deleting the
associated specialized information. (I think--I still need to solve some
details there.)
You can do this anyway. The aspnet membership tables are just SQL Server
tables. There's nothing magic about them. You can add relational constraints
to them all you want.
In addition, since creating a user involves adding records to more than
one table, I could use transactions. It doesn't appear that I can create a
user with the default provider and then create a record in the secondary
table all within a single transaction.
Good point ... maybe. See below.
Finally, I started wondering if it might just be easier as I seem to spend
a lot of time trying to figure out exactly how the default provider works.
I've always enjoyed creating something more than trying to figure out what
someone else has done.
I'm with you on this one. However, I'm not sure that creating your own
Membership provider is going to accomplish that. As you've already seen, the
membership interface defines the methods that you must implement and the
built-in login controls call those methods automatically. You still have to
work within the framework that someone else built. Which means that you
still need to understand that framework. And that framework may not allow
for passing all of your custom data around easily.
For example, the "Membership.CreateUser" method doesn't provide arguments
for user preferences. So you're going to need another method call to push
the preferences to the DB. That method call isn't going to be called by the
built-in controls, so you'll have to add events to those controls to call
the additional methods. I'm not sure that you are going to be able to get
all of that to happen in a single database transaction.
IMO, the membership interface is useful for supporting non-SQL Server
databases and little else. It's a DAL, not a place for customized business
rules. If you want purely custom business rules, I'd say abandon aspnet
membership and just roll your own. It's not like it's *that* hard. The whole
point of aspnet membership was to automate and simplify a routine web site
task. For us, it made more sense to use that tool "as is" then add more
information "on top" of it.
Scott