Ваш вопрос немного не детализирован, но я хочу ответить.
Для начала вам не нужно наследовать от класса MembershipUser.Вы можете (потому что это абстракция), но вы бы унаследовали его только в том случае, если бы собирались использовать свою собственную логику и таблицы БД для хранения полей проверки.
Вы бы не поместили членство в класс университета или компаниино для членов этих организаций, например, студент является членом университета, поскольку в компании есть сотрудники.
Ни у студента, ни у сотрудника не будет информации о членстве (в их таблицах БД), ноболее вероятно, будет иметь информацию, относящуюся непосредственно к ним (например, у сотрудника есть номер платежной ведомости)
Студент и сотрудник относятся к типу Персона (например, у них обоих есть Имя, Адрес и т. д.)
Студент или Сотрудник может быть Пользователем вашего Приложения (веб-сайт, рабочий стол и т. Д.), Но в противном случае они могут быть также нет, или они могут быть деактивированы в качестве Пользователя, но вы хотите сохранить информацию об их Персоне и Студенте / Сотруднике для своих записей..
Пользователь будет иметь обычную информацию, такую как ... Идентификатор пользователя, Имя пользователя и Пароль и т. Д., Но выне хотите использовать эту сущность, если вы собираетесь поместить DisplayName в приложение.Из соображений безопасности я также не помещаю информацию о сеансе в пользователя, а использую UserId (одностороннее шифрование MD5) и SessionId для проверки сеанса моих пользователей, это означает, что если у меня возникли проблемы с безопасностью (инъекция SQL)хакер не сможет получить доступ к именам пользователей и паролям.В любом случае, я отвлекся.
Итак, что такое класс MembershipUser?Он используется главным образом в вашем объекте аутентификации, который будет иметь такие методы, как ... Login, ChangePassword, Logout и т. Д. Эти методы будут вызывать
if (! Membership.ValidateUser ('username', 'password'))вернуть ложь;и т. д.
Если вы хотите использовать свои собственные таблицы БД и вызовы entityframework для членства, тогда вы бы хотели реализовать пользовательского поставщика членства, переопределяя все стандартные методы и выставляя вам запросы DAO объекта (надеюсь, с использованием шаблонов проектирования).например, хранилища и т. д.).Это может быть рискованно и сложно, но с опытом не так уж и сложно.
В противном случае, просто придерживайтесь стандартного членского (пользовательского) провайдера, вставьте то, что ему нужно, в файл web.config и решите, как с ним работать.безопасность, и вы можете приступить к разработке своего приложения ...
хорошая книга - Pro Asp.Net MVC Framework ... она рассматривает все, включая модульное тестирование, шаблоны проектирования и т. д.потратить немного денег на исходный код шаблонов проектирования GOF (Gang of Four) ... получить полную работу, лучшие £ 60 за все время.
Надеюсь, это помогло.
Хью