Расширение профиля участника еще двумя слоями - asp.net mvc

Question

У меня вопрос моделирования, связанный с профилями. Во-первых, я рассмотрел использование SQLTableProvider и встроенную систему профилирования, но не чувствовал, что они подходят. Итак, с учетом сказанного, у меня есть схема членства, в которой у каждого человека есть свой профиль, и тогда он может обновить свой профиль либо до отдельного (дополнительные поля), либо до корпоративного аккаунта (снова дополнительные поля).

Итак, я подумал, используйте базовый класс Profile, а затем наследуйте его для корпоративного и индивидуального аккаунта. Однако, когда дело доходит до реализации этого в MVC, я бью кирпичную стену.

Поскольку либо страницы редактирования компании, либо отдельные страницы эффективно обновляют как базовую таблицу профиля, так и отдельные таблицы / таблицы компаний с одной и той же страницы. Как бы я реализовал это внутри модели (которая в настоящее время генерируется через LinqToSQL), а также на уровне представления?

Извинения, если это было не очень ясно, сложно объяснить!

Answer 1

Если вы используете Linq to SQL, значит, у вас уже есть модель. Linq генерирует объекты и коллекции на основе вашей базы данных для вас. Сгенерированная модель является поверхностной, но довольно надежной и работоспособной. Модель Linq to SQL может быть расширена с помощью частичных классов, что позволяет расширять сущности или сам контекст для дополнительной функциональности.

Контроллер может работать напрямую с сгенерированной моделью и при необходимости передавать сущности или коллекции сущностей в представление.

Я бы предположил, что для того, что вы пытаетесь сделать, вы можете вообще не использовать встроенную систему провайдеров профилей. Поставщики профилей в asp.net работают хорошо для простых вещей персонализации, но они не работают хорошо для конкретных данных, таких как контактная информация и тому подобное. Также имейте в виду, что системы провайдеров профилей, как правило, хранят объектные данные в виде сериализованных строк в базе данных ... это очень затрудняет получение данных профиля из инструментов администратора и тому подобного. Производительность начинает становиться проблемой ОЧЕНЬ быстро в любом случае, когда вам нужна информация профиля нескольких пользователей (например, с редактором администратора).

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

Мое эмпирическое правило таково: если информация требуется ТОЛЬКО во время запроса, сделанного пользователем, которому принадлежат данные, то она отправляется в профилях. Если мне понадобятся данные для одного пользователя для чтения во время запроса другого пользователя или если мне понадобится «список» этих данных для разных пользователей, то они не будут включены в профили asp.net.

Answer 2

Вы имеете в виду такие настройки, как выбор количества элементов для просмотра на каждой странице и выбор таблицы стилей?

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

Компания выбирает некоторые значения, которые будут работать для пользователей, если пользователи не выбрали для себя некоторые другие значения. Это то, что ты имеешь в виду?

---

В этом случае: я не знаю, как сделать это вместе в профиле ASP.NET, но как насчет следующих таблиц в базе данных:

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
)

А затем сделайте несколько соединений для настоящего пользователя. Если пользовательская настройка не указана, возьмите настройку компании; если настройка компании не указана, примите значение по умолчанию.