Я поступаю об этом неправильно? - PullRequest
1 голос
/ 09 октября 2009

Это мое первое приложение MVC / Linq to SQL. Я использую стандартное членство SQL в ASP.NET для отслеживания пользователей в моей системе.

Как большинство из вас знает, UserId - это гид, отлично. Однако, чтобы связать другие пользовательские таблицы в системе, я решил использовать имя пользователя вместо идентификатора пользователя. Я сделал это потому, что:

  1. Имя пользователя в любом случае уникально
  2. Это не позволяет мне делать дополнительный вызов при обработке функций БД.

Так, например: мне не нужно искать идентификатор пользователя на основе имени пользователя, чтобы создать новую историю; Я просто вставляю User.Identity.Name в таблицу истории.

Теперь я столкнулся с некоторым неприятным осложнением, которое, похоже, связано с этим. Он работал нормально на моей локальной машине, но не на хосте. Я постоянно получал сообщение об ошибке, похожее на это:

"System.InvalidCastException: указанное приведение недопустимо. На System.Data.Linq.IdentityManager.StandardIdentityManager.SingleKeyManager" ...

Это происходило всякий раз, когда на хосте происходила вставка в базу данных. Если я правильно понимаю, это ошибка в настоящее время, которая возникает, когда вы связываете нецелочисленное поле (в моем случае имя пользователя) с другой таблицей нецелочисленного поля (имя пользователя в aspnet_user). Хотя представленная ошибка кажется немного другой, может быть, они похожи?

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=351358

В любом случае, ошибка MS или нет - плохая идея хранить имя пользователя вместо идентификатора пользователя в моих таблицах? Если это так, то почему?

Обновление

Я просто хотел добавить сюда больше контекста. Хорошая мысль, которую люди поднимают, заключается в том, что это опасно, если я хочу разрешить пользователям менять свое имя пользователя в будущем. Совершенно верно!

Однако, это приложение сильно зависит от имени пользователя. Каждый пользователь создает одну и только одну историю. Затем они ссылаются на свою историю, используя: mysite / username. Поэтому приложение никогда не позволит им изменить свое имя пользователя. Это может вызвать потенциальный кошмар у людей, которые переходят по ссылке, чтобы увидеть, что ее больше не существует.

Ответы [ 5 ]

1 голос
/ 09 октября 2009

Я думал только о том, чтобы в будущем проверить ваше приложение, идентификатор пользователя предоставил бы гибкость пользователям, меняющим свое имя пользователя, так как идентификатор пользователя оставался бы постоянным (как, например, SO). Но это то, что должно соответствовать требованиям вашего приложения. С другой стороны, требования часто имеют тенденцию меняться без контроля разработчика.

1 голос
/ 09 октября 2009

Будьте внимательны в отношении вашего комментария относительно уникальных имен пользователей. В ту минуту, когда Анита Такеабат выходит замуж за Сеймура Баттса, внезапно наступает желание быть примыкающим.

Просто мысль!

1 голос
/ 09 октября 2009

Я использовал тот же подход, что и вы, и он работает. Есть ли у вас связь между таблицей приложения и таблицей из базы данных о членстве? Если это так, вы можете удалить это отношение.

0 голосов
/ 09 октября 2009

Если причина, по которой вы реализуете это, заключается в облегчении доступа к GUID пользователя, я предлагаю, чтобы ваш FormsAuthentication.SetAuthCookie использовал GUID пользователя в качестве свойства имени и использовал User.Identity.Name во всем приложении.

Использование имени пользователя в качестве уникального идентификатора может иметь плохие последствия в будущем. Если вы захотите позволить пользователю изменить свое имя пользователя в будущем, вам будет трудно реализовать это.

0 голосов
/ 09 октября 2009

Это плохо по следующим причинам:

  1. Вы упомянули, что избегаете дополнительных вызовов базы данных. Однако при объединении таблиц «лишних» обращений к базе данных нет. Вы можете утверждать, что присоединение стоит дороже, чем вообще не присоединяться. Однако, скорее всего, магазину нужно больше информации о пользователе, чем имя пользователя (примечание: имена пользователей не уникальны, имена пользователей уникальны). Таким образом, вам все равно нужно присоединиться для большинства операций с базой данных.

  2. Имена пользователей имеют разную длину, они плохо работают, когда они используются при присоединении.

Редактировать: измененный формат. Я все еще учусь, как сделать мой пост лучше: -)

...