Как бы вы использовали Entity Framework (1.0) с членством в ASP.Net?

Question

Я пытаюсь разработать модель объекта для приложения, которое использует членство ASP.Net для аутентификации пользователя. В большинстве схем баз данных, которые я создаю, записи обычно связаны с пользователями через поле UserId в таблице aspnet_users. В прошлом это работало нормально, но теперь, когда я использую EF, у меня возникли некоторые концептуальные проблемы с выяснением того, как я собираюсь ссылаться на пользователя из сущности.

Например, допустим, у нас есть сущность "post", которая содержит свойство "postsBy". Мне бы хотелось иметь возможность получить имя пользователя, который создал этот пост, с чем-то вроде post.user.username, но я опасаюсь создавать сущность на основе таблицы aspnet_user, опасаясь создания модели, которая позволяет Обойти класс Membership при внесении изменений в базу данных.

Я рассмотрел вопрос о том, чтобы просто оставить поле post.userId в качестве guid, а затем потребовать, чтобы любой код, которому необходимо знать имя пользователя, использовал этот guid для получения пользователя из класса Membership, но это кажется «неуместным». *

У кого-нибудь есть какие-либо рекомендации по проектированию моделей объектов, которые интегрируются с Членством? Было бы разумно случиться с пользовательским объектом «только для чтения».

Answer 1

Мой совет: «Не надо».

Позвольте мне быть более конкретным.

Использование UserId в качестве сопоставленного внешнего ключа связывает вашу модель сущности не с членством ASP.NET в целом, а с поставщиком членства SQL в целом. Что произойдет, если вы затем захотите использовать аутентификацию домена или OpenID?

Не поймите меня неправильно: в 99,9% случаев правильно связывать ссылки на БД вместе с внешним ключом. Черт возьми, вы могли бы даже сделать это здесь, но не отображайте это в вашу модель сущности. Вы должны держать стену логического разделения между поставщиками членства и вашими собственными данными. Вы получаете доступ к своим данным через EF. Вы получаете доступ к данным членства через API членства. Тот факт, что они живут в одной и той же БД, поскольку вы используете поставщика членства SQL, является подробностью реализации.

Обновление: Я развил эту идею в сообщении в блоге .