Возможно ли иметь несколько профилей в ASP.NET для разных пользователей?

Здесь у вас действительно есть только 2 варианта:

1. Вы можете просто создать «большой» профиль с полями для всех типов пользователей, а затем получить доступ только к полям для того типа пользователя, который вы используете в данный момент. (Я не рекомендую это, но это может быть быстрое решение).

2. Реализовать поставщика пользовательских профилей — это совсем не сложно. Подробнее об этом можно узнать здесь: http://msdn.microsoft.com/en-us/library/0580x1f5.aspx

РЕДАКТИРОВАТЬ 2015-01-26: Хм... у меня только что поднялось 1, но я действительно думаю, что этого не должно было быть. Теперь, когда я перечитал вопрос и свой собственный ответ более 2 лет назад, я на самом деле НЕ думаю, что группы профилей - это способ включить несколько «типов» профилей. Возможно, вы могли бы поместить свойства двух разных типов в две разные группы (по крайней мере, «ортогональные» свойства), но вам все равно нужен код, чтобы различать их. Так что я бы выбрал apiguy или ответ Джима Шуберта ENDEDIT

Разве это не группы профилей? для? Нравится:

<profile>  
  <properties>  
    <group name="UserInfo">  
      <add name="Name"/>  
      <add name="Age"/>  
    </group>  
    <group name="MemberInfo">  
      <add name="MemberID"/>  
      <add name="JoinDate"/>  
    </group>  
  </properties>  
</profile>

Да, боюсь, вам придется указать все возможные свойства, если вы собираетесь использовать модель профиля. Если вы пойдете по этому пути, я бы предложил использовать какой-то прокси-сервер, который будет принимать пользователя и в зависимости от его типа заполнять соответствующие свойства.

что-то типа

public static class ProfileProxy<T>
{
    public static void FillProperties(T user)
    {
        if(user is Teacher)
        {
            //Pull & fill profile properties for teacher
        }
        else
        {
            //Pull & fill profile properties for student
        }
    }
}

Я бы подумал о том, чтобы иметь две разные таблицы, которые разделяют два объекта или реализуют поставщика настраиваемого профиля.

Вы можете создать объект и сохранить его в профиле. Например:

[Serializable]
public class ProfileObject { }

[Serializable]
class StudentProfile : ProfileObject
{
    public string Year {get;set;}
    public string Name {get;set;}
    public string Age {get;set;}
}

[Serializable]
class TeacherProfile : ProfileObject
{
    public string Department {get;set;}
    public string Tenure {get;set;}
    public string Rating {get;set;}
}

В веб.конфигурации:

<profile>
...
      <properties>
        <add name="UserProfile" allowAnonymous="false" type="ProfileObject" serializeAs="Xml"/>
      </properties>
</profile>

Редактировать: я не могу вспомнить, можете ли вы использовать интерфейс в качестве типа или нет. Изменил его на объект.

Доступ к этому через Profile.UserProfile (избыточно, но работает). Затем, чтобы обработать это, вам нужно будет проверить тип:

if(Profile.UserProfile is StudentProfile) { /* do something */ } else
if(Profile.UserProfile is TeacherProfile) { /* do something */ } // etc.

Вы также можете хранить дженерики в объекте профиля (возможно, словарь? Ниже приведена реализация, которую я использовал)

Например:

namespace Model
{
    [Serializable]
     public class RecentlyViewed : List<Model.Product>
     {
         public RecentlyViewed() {}
     }
 }

И в web.config:

 <profile>
...
      <properties>
        <add name="RecentlyViewed" allowAnonymous="false" type="Model.RecentlyViewed" serializeAs="Xml"/>
      </properties>
</profile>

Я использовал этот метод в .NET 3.5, я не уверен, работает ли он в .NET 2 или 3. Я предполагаю, что дженерики обрабатываются одинаково, поскольку компилятор не изменился.

Примечание. Необходимо наследовать универсальный объект в пустой объект, потому что настройкам профиля не нравится следующее:

<profile>
...
      <properties>
        <add name="RecentlyViewed" allowAnonymous="false" type="System.Collections.Generic.List`1[Model.Product]" serializeAs="Xml"/>
      </properties>
</profile>

Выше приведено полное имя IL, как оно должно выглядеть. Кажется, что XML не нравится галочка.

Я не исследовал никаких проблем с производительностью при хранении сериализованных объектов в объекте Profile, и поэтому я бы не рекомендовал это для каких-либо свойств, которые вам понадобятся на довольно регулярной основе.