DotNetNuke PersonalizationController Architecture / Replacement

Question

I’ve created a custom MembershipProvider that uses the DotNetNuke.Security.Membership.MembershipProvider as a base. In our implementation, a CRM system stores all contact data for users able to connect to any of our websites, and therefore such functionality as CreateUser and DeleteUser are not implemented. The MembershpProvider only handles authentication, membership and returning a UserInfo object with the CRM system’s data.

This works fine.

The problem I’m running into is with the PersonalizationController. Our CRM system stores information regarding the user/contact, but not regarding the user’s personalization settings. I would like for DNN to continue to store the personalization settings as defined in the PersonalizationController / PersonalizationModule (e.g., in the Profile table). The problem is, when the LoadProfile() stored procedure is called by the DataProvider it fails on an update because the Profile table has a constraint associated with it requiring the UserId to have already been added to the User table. I could modify this Foreign Key relationship but that wouldn’t be good architecture.

So, the question is: What would be a good architecture choice in this situation?

The MembershipProvider and DataProvider follow the Provider Model, so they can be replaced, but I don’t want to replace the DataProvider. The PersonalizationController doesn’t follow the Provider Model and therefore cannot be so easily replaced. Updating the Stored Procedure or the Foreign Key would potentially cause upgrade issues (or at least make debugging years later hard / require good documentation). Likewise with changing the source code (I could simply update the PersonalizationController, line DataProvider.Instance().AddProfile(userId, portalId); with a call to first add the user to the Users table (which should be unnecessary – yes, I understand the difference between the Users and aspnet_Users tables, so theoretically, adding a User record should be OK, albeit superfluous simply because of a Foreign Key. I could also update the MembershipProvider with an insert into the Users table -- this is the direction I'm currently thinking about (although I don't really want to).

Any ideas how I can replace the PersonalizationController using a Provider Model? Or how else I can minimize upgrade or management issues down the line? I’m really trying to build a system where we can at any time install DNN fresh and simply install all our Modules / Providers / Skins on it and replicate the existing system (without content, of course).

What would be the recommended way / recommended architecture in this situation?

Thanks in advance.

Greg

Answer 1

Would it make sense to keep the UserID in the DNN database, so that you can utilize all of those keys that many different modules may have on the Users table. If you don't have userids, it is very likely that you will run into module issues down the line.

The AD provider for DNN creates DNN users, and matches those up to AD users, to get around this issue.