MVC Membership - User details

Hi

First time using Membership provider with Lightspeed. What approach do you recommend for storing user details - first name, last name, address etc. eg. Drag the aspnetUsers table onto the Lightspeed designer, then create a UserDetails entity with a one-to-one relationship to aspnetUsers?

Many thanks.

You could do this although from memory the model is a bit obtuse and you would have to them implement your own provider which utilizes the LightSpeed model, am reason for not just use the standard SQL based provider verbatim?

Jeremy

I guess the main reason for wanting to manage user profile details through Lightspeed is just so that all my querying is done the same way; the LS unit of work. (As opposed to using LS for products etc and another construct for user info.) And at some point I might want to have users and products in the same query eg. Return products that were purchased by users with a date of birth between 1980 and 1990.

Does that make sense, or am I missing something?

Thanks.

No that makes sense, if you are just intending to query over that data via LS then you may want to still use the stock membership provider since there is quite a bit of work involved in implementing a custom one, and then you can just add those tables to the model and query over them as required within your application context.

Ive had a check on how these map here and they are using a common PK/FK for the Aspnet_Membership table which is not something we support mapping for so to get this to work just manually remove the association between these two classes in the LightSpeed model and then query against the relationship manually instead.

Jeremy

Cool, thanks for the info. A couple of questions:

1. "if you are just intending to query over that data via LS then you may want to still use the stock membership provider" - Do you mean it would be ok to run SELECT queries as opposed to UPDATE with LS? In other words, getting the data out would be safe with LS but saving changes might not be?

2. "manually remove the association between these two classes in the LightSpeed model and then query against the relationship manually instead" - Would this mean that I could no longer update the database from the LS model or vice versa?

Cheers.

No in both cases. Once you have the model defined in LightSpeed you can query and update as normal.

re #1 - My suggestion for using the stock membership provider rather than writing your own is just because writing a membership provider takes a lot of work, so if you are simply going to be duplicating the functionality of the standard membership provider then it would seem like a lot of effort for no change but you certainly could do this. You would want to write your own membership provider if you wanted to leverage other concerns from your model though.

re #2 - You will need to make this change to make the model validate to LightSpeeds conventions. "query against the relationship manually" just means that if you want to find the User associated with a Membership you would need to issue a specific query e.g.

unitOfWork.FindById<AspNetUser>(aspNetMembership.Id);

rather than traversing the association. As above it has no impact on behaviour, its just a modelling related tweak you need to make to make the model validate.

Jeremy

Great, thanks.

Hi again. Just getting back to looking at this.

Regarding your answer to no.2 above, if I add the AspnetUser and AspnetMembership tables to the LS model, then delete the relationship between them on the model, then if I needed to "Update database..." from the model it wants to "Delete column UserId and assocated foreign key from table aspnet_Membership" - which would have to be bad, right?

Yes you will want to ignore that because you want the database schema to remain unchanged.

Jeremy

Ok, that was what I meant with my question 2 above which realise now was a bit ambiguous. I can then no longer update the database schema by selecting "Update database" from the Lightspeed model because it will destroy that association. I guess I could just uncheck that particular update each time but if I forgot to do that even once it would be a bummer!