Здравствуйте, parapet, Вы писали:

P>Есть 2 типа пользователей (companies и students), которые имеют различный контекст, т.е. например companies имеет companyName, Address и т.д., students имеют FirstName, LastName и т.д. Как хранить их в Profile? Первое, что приходит на ум — это в разных group. Или есть более разумный подход (можно ли создать класс профиль для компаний и отдельный для студентов)?
P>Второй вопрос — как осуществлять поиск и сортировку по полям профиля в случае надобности?


Не стоит спешивать грешное с праведным.

Есль подойти с позиции ООП, то у нас есть два объекта: Company & Student

Эти два объекта приблизительно выгледят так:


public class Company
{
    public string Name;
    public string Address;    
}

Так же у нас есть объект Student, а выглядит он, приблизительно, так:


public class Student
{
   public string FirstName;
   public string SecondName;
}

Если мы внимательно посмотрим, то ни чего похожего нет между ними. Да возможно вы заметили, что все описания объекта имеют тип string — это не больше чем воппадение.

Хранить их в базе на много проже поотдельности, не заморачиваясь с Profiles Providers — там своих ограничений хватает.

Создаём таблички, скажем, в MSSQL'e да бы не заморачиватся с поиском ADO.NET провайдеров и прочим:


CREATE TABLE [dbo].[Companies] (
  [company_id] int IDENTITY(1, 1) NOT NULL,
  [name] varchar(100) COLLATE Cyrillic_General_CI_AS NOT NULL,
  [address] varchar(100) COLLATE Cyrillic_General_CI_AS NOT NULL,
  PRIMARY KEY CLUSTERED ([company_id]),
  UNIQUE ([name])
)
ON [PRIMARY]
GO
-- А так же табличку Studients

CREATE TABLE [dbo].[Studients] (
  [student_id] int IDENTITY(1, 1) NOT NULL,
  [FirstName] varchar(100) COLLATE Cyrillic_General_CI_AS NOT NULL,
  [SecondName] varchar(100) COLLATE Cyrillic_General_CI_AS NOT NULL,
  PRIMARY KEY CLUSTERED ([student_id]),
  UNIQUE ([name])
)
ON [PRIMARY]
GO

С хранилищем вроде бы разобрались, теперь переходим к Data Access Layer & Bussines Logic Layer
Переписывать то, что было и так толково написано — не буду.

Вот почитай-те сами:
Tutorial 1: Creating a Data Access Layer
Tutorial 2: Creating a Business Logic Layer

Я внесу только не значительные коментарии:
Создайте DataSet. В нём создайте два TableAdapter'a: CompaniesTableAdapter & StudientsTableAdapter. Если особо не вмешиватся в процесс,
то механизмы добавления, удаления и изминения будут.

Остаётся добавить только методы для поиска информации. Каждому из TableAdapter'ов, к примеру SdutientsTableAdapter добавляем метод:
GetStudentsByFName.

Код запроса приблизительно такой:

SELECT [student_id], [FirstName], [SecondName] FROM [dbo].[Students] WHERE [FirstName] LIKE @query;

В итоге вы сможете вызывать просто функцию которая будет возвращать вам тех, кого вы хотите найти.

Если будут вопросы — пишите.

Здравствуйте, parapet, Вы писали:

P>ЗЫ. Спасибо конечно за подробный ответ, но он мне излишний — я это делал сотни раз :) Просто хотел поинтересоваться оправдано ли в данном случае использовать Profile ;)

Ввиду дизайна Profile Provider'a могу предположить, что он создан для того, что бы добавлять любые описательные свойства.
В вашем случае, это возможно могут быть Students.

Но ввиду простоты реализации можно и переписать, что бы данные складывались так, как вас устраивает в БД.

Здравствуйте, parapet, Вы писали:
P>а почему Students? почему не Companies?
Я понимаю, что есть соблазн использовать Profile в качестве доступа к базе данных.
Но этот вид хранилища разработал именно для того, что бы хранить описательные данные тех объектов,
которые будут использовать сайт. В 99.9% случаев это Users. Я контекств ваш не очень знаю, по этому предположил что
Users == Students.

Вообщем-то компании тоже можно пож это подвести, если скажем стоит задача: Для компакии "Рога и копыта" — сайт будет цвета слоновой кости,
а для тех, кто пользуется сайтом из компании "Microsoft" — бело-голубым.

В этом случае, действительно Profile можно использовать для сущности Companies.

N>>Но ввиду простоты реализации можно и переписать, что бы данные складывались так, как вас устраивает в БД.

P>Да, только делать один профиль для двух различных сущностей как-то э... :) Как вариант — нельзя ли создать 2 типа профилей? Конечно можно их в разные Group засунуть, но все-равно как-то не то :)

%)