Должна ли моя модель пользователя наследовать MembershipUser - PullRequest
Новая
       18

Должна ли моя модель пользователя наследовать MembershipUser

2 голосов
/ 24 февраля 2012

Я смотрю на создание настраиваемого поставщика членства в ASP.Net MVC3 и пытаюсь понять, как все это сочетается ...

Я действительно ищу подходы, как это сделать.

У меня есть модель User (представление таблицы Users в моей базе данных). Чтобы использовать это с функциональностью MembershipProvider, должна ли эта модель наследовать MembershipUser? В MembershipUser есть ряд полей, которые меня не волнуют - должны ли они быть в базовой таблице SQL, чтобы этот подход работал (очевидно, это кажется избыточным, поскольку я никогда не буду использовать столбцы?)

Например - я должен заставить мою модель наследовать MembershipUser, как это? 

/// <summary>
/// Class representing a registered user based on the Users database table.
/// </summary>
public class User : MembershipUser
{
    public int Id { get; set; }
    //here I can access some other properties I will use which are already in MembershipUser...

    //Addtional properties I need specific to my app.
    public bool NotifyOfNewBlog { get; set; }
    public bool NotifyOfNewWallPosts { get; set; }
    //...plus many more.
}

Когда речь идет об использовании Membership.GetUser() дальше по линии, могу ли я приводить этот объект каждый раз обратно к моему исходному объекту User, чтобы иметь доступ к дополнительным свойствам?

Это подход, который я должен использовать? Или мне нужна отдельная модель User, а затем модель CustomMembershipUser, которая связана с моделью БД?

Сможет ли EF сохранить / обновить / вставить модель пользователя, если в ней нет всех столбцов MembershipUser в качестве объектов в таблице? Это даже где-нибудь рядом с правильным подходом? Как видите, я немного чешу здесь голову.

Любые советы / мысли / идеи очень ценятся.

Ответы [ 2 ]

1 голос
/ 24 февраля 2012

Некоторое время назад у меня была такая же проблема, и в итоге я решил не загрязнять свои модели EF логикой членства. У меня есть уровень доступа к данным в моем приложении, и мой EFMembershipProvider использует его, когда ему нужно сохранять / обновлять данные. Если мне нужно GET пользовательских данных в моем приложении (кроме самого членства), я не использую членство (и мне не нужно ничего разыгрывать).

Я хочу прояснить, что если вы внедрите своего собственного провайдера членства 

public class EFMembershipProvider : MembershipProvider

вы можете абстрагировать базовую функциональность механизма членства, чтобы использовать ваши собственные модели / репозитории.

Пример встроенного поставщика членства для EF можно найти в шаблоне MVC3

https://github.com/crdeutsch/MVC3-Boilerplate

В Web / Инфраструктура (хотя вы, вероятно, хотите изменить ее большие части).

1 голос
/ 24 февраля 2012

Что касается наследования объекта MembershipUser, вы могли бы сделать это, и в вашей реализации MembershipProvider просто приведете к вашему производному типу, но я лично не буду этого делать, просто потому что вызатем во власти будущих изменений этого типа нарушить ваш производный тип (хотя это можно сказать о большей части фреймворка, я думаю).Вместо этого я бы поместил эти дополнительные значения в профиль и свернул свой собственный ProfileProvider (не используйте Sql, который по моему опыту является мусором).

"В MembershipUser есть несколько полей, которые яне волнует - должны ли они быть в базовой таблице SQL, чтобы этот подход работал (очевидно, это кажется излишним, поскольку я никогда не буду использовать столбцы?) "

Если вы катите свои собственные,Вы можете просто не сохранять это в БД.В конце концов, вы реализуете методы MembershipProvider (GetUser и т. Д.), Поэтому то, что вы делаете с переданным вам объектом MembershipUser, зависит от вас.Вы можете просто игнорировать их, а не проверять или хранить их.

...