Рекомендации по схеме данных с использованием .Net Membership Provider - PullRequest
2 голосов
/ 23 января 2012

Я работаю над приложением MVC 3, использующим членство в .NET и использующим Entity Framework для доступа к данным.Я довольно новичок в использовании этих технологий.Я продолжаю сталкиваться с зависаниями, когда пытаюсь связать данные приложения с конкретными пользователями.

Итак, допустим, у вас есть пользователь, который был создан с помощью .NET Membership Provider, и в качестве этого пользователя вы создаете определенные объекты приложения, которыедолжен быть привязан именно к этому пользователю.Каждый пользователь получит доступ к своему списку этих объектов.Мне любопытно, какой будет лучшая практика.Мне нужно создать внешний ключ для этих объектов приложений, чтобы я знал, что они принадлежат определенному пользователю.Я просто не уверен, каким должно быть это значение.

Кроме того, допустим, у вас есть пользователь-администратор, который может видеть все эти объекты приложения для каждого пользователя и какому пользователю он принадлежит?Используя Entity Framework, я хотел бы иметь возможность выполнить такой запрос.Но у вас обычно нет сущностей, которые представляют объекты членства.

Надеюсь, я достаточно хорошо проиллюстрирую свою путаницу.Пожалуйста, дайте мне знать, если я неясен.Любая помощь, которую кто-либо может оказать в этом, будет оценена.

Спасибо

1 Ответ

0 голосов
/ 23 января 2012

Всякий раз, когда я разрабатываю приложение, которое выходит за рамки того, что предлагает поставщик членства .NET, я создаю свои собственные таблицы в базе данных приложения для пользователей, профилей пользователей и ролей.Это даст вам гибкость в разработке информации, которую вы хотите сохранить для пользователей, и тогда вы сможете использовать EF для доступа к этой информации.Какой подход EF вы используете;это сначала код, модель или база данных?Если вы используете код вначале, EF создаст для вас отношения, создав идентификаторы объектов типа int в БД, для которых задано значение «Is Identity» и само приращение.Вы можете переопределить это, используя атрибуты в свойствах ваших объектов, например так:

    [Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public Guid ID { get; set; }

Использование int обеспечивает более эффективную индексацию, но Guid полезны, если вы используете реплицированные или распределенные базы данных.Вы можете использовать любую опцию для поддержания отношений между объектами, если вы используете подходы сначала модель, либо база данных.Используя концепцию идентификаторов объектов вместо использования других первичных ключей, дайте пользователю возможность изменять информацию пользователя, не портя отношения таблиц.Например, если первичным ключом для пользовательской таблицы является имя пользователя, и пользователь решает изменить свое имя пользователя, вам также потребуется обновить все внешние ключи.

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

...