As soon as I saw the code sample on K. Scott Allen’s latest blog post, I knew he was talking about the Membership Provider.
His example nails it when describing the complexities of defining a
contract via an interface. It just isn’t expressive enough.
Documentation is always necessary.
I ran into this recently when trying to implement a custom
Membership Provider for DotNetNuke. It turns out that DotNetNuke
maintains its own user and role tables. These “satellite” tables map to
the ASP.NET membership tables (but do not have any foreign key
constraints) since they provide more information specific to
DotNetNuke.
So how do the satellite DNN tables stay in synch with your provider
data store? Well when you login and DNN doesn’t have a record of the
current user, DNN will call into your provider to get a list of users
and then it iterates through each one adding the user to its own user tables if the user doesn’t already exist.
I couldn’t even get the roles to synchronize properly, but I didn’t
spend enough time. What I discovered is that following the Membership
Provider contract wasn’t enough. I actually needed to know what the
consumer was doing with my provider to understand why it would take so
long to login a user.