Extending a member profile with two further layers - asp.net mvc

Hi, both a newbie to stackoverflow and also a newbie to the world of C# and ASP.NET MVC (lots of learning at the moment!) but an experienced web developer.

So I have a modelling question related to profiles. Firstly, I have looked into using the SQLTableProvider and using the in built profiling system but didn't feel they were suitable. So, with that said, I have a membership scheme where every person has a profile, then that person can upgrade their profile to either an individual (additional fields) or a company account (additional fields again).

So I thought, use a Profile base class and then inherit from that for the Company account and Individual account. However, when it comes to implementing this in MVC I'm hitting a brick wall.

Since either the company or individual edit pages are effectively updating both the base Profile table and also the individual/company tables from the same page. How would I go about implementing this within the model (which is currently generated via LinqToSQL) and also at the view level?

Apologies if that wasn't very clear, tricky one to explain!

From stackoverflow

• Do you mean settings like choosing how many items to view on each page, and choosing some style sheet?

  public class Profile
  {
      int? ItemsPerPage { get; set; }
      string PreferredStyleSheet { get; set; }
  }
  

  The company selects some values that will work for users unless the users have chosen some other values for themselves. Is that what you have in mind?

  ---

  In that case: I don't know how to do it together in ASP.NET Profile, but how about the following tables in the database:

  TABLE Setting
  (
      SettingID int NOT NULL,
      SettingName varchar(32) NOT NULL,
      DefaultValue nvarchar(128) NULL
  )
  TABLE CompanySetting
  (
      CompanySettingID int NOT NULL,
      RefSettingID int NOT NULL,
      RefCompanyID int NOT NULL,
      SettingValue nvarchar(128) NOT NULL
  )
  TABLE UserSetting
  (
      UserSettingID int NOT NULL,
      RefSettingID int NOT NULL,
      RefUserId uniqueidentifier NOT NULL,
      SettingValue nvarchar(128) NOT NULL
  )
  

  And then make some joins for the present user. If the user setting is not given, take the company setting; if the company setting is not given, take the default value.

  Steve : Thanks Ole, but not really what I was after. The details for each of the different types of profile are the likes of address details, job experience that type of thing. I've got the database modelled fine, its carrying that over to MVC that I'm having trouble with. As in how to represent the table structure on the model layer and show them in the views. Make any more sense?

• If you are using Linq to SQL, then you already have a model. Linq generates the entities and collections based on your database for you. The generated model is a shallow one, but is pretty solid and workable. The Linq to SQL model can be extended via partial classes allowing you to enhance entities or the context itself for additional functionality.

  The controller can work directly against the generated model and pass entities or collections of entities to the view as needed.

  I would suggest that, for what you appear to be trying to do, you might consider not using the built-in profile provider system at all. The profile providers in asp.net work well for simple personalization stuff, but it doesn't work well for concrete data like contact info and such. Also keep in mind that the profile provider systems tend to store object data as serialized strings in the database... this makes getting at profile data very difficult from admin tools and such. Performance starts to become a problem VERY fast in any case where you are needing multiple user's profile information (such as with an admin user editor).

  For a when you are storing important personal details like the stuff you mentioned, what you are really storing are "account details" not "user profiles". You can extend a membership provider to expose your additional details, but I've generally found it much easier to just roll my own data model and access logic to deal with the additional account information.

  My rule of thumb is this: if the information is ONLY needed during a request made by the user to whome the data belongs, then it goes in profiles. If I would need the data for one user to be read during another user's request, or if I would need a "list" of that data for different users, then it doesn't go in asp.net profiles.

  Steve : Thanks for the input Stephen. I did decide against using the inbuilt profiles for the very reasons you mentioned so good to know I was thinking on the right tracks there. Thinking about it more, I think my main issue was surrounding the updating of two tables/models from one view/controller action but I'm pretty sure I've got the way forward on that now.