Должен ли я передавать UserID между уровнями приложения? - PullRequest
Новая
       14

Должен ли я передавать UserID между уровнями приложения?

0 голосов
/ 07 февраля 2009

Когда вы отправляете данные на уровень данных, когда userID не является полем в передаваемом объекте, но при отправке данных все равно потребуется перекрестная ссылка на таблицы с userID, я должен вызвать класс членства, чтобы получить UserID на уровне данных или я должен передать UserID от уровня к уровню в качестве параметра? (то есть от бизнес-уровня до уровня данных?) (Или это не имеет значения в любом случае?)

Контроллер или бизнес-уровень: 

 MembershipUser user = Membership.GetUser();
 Guid userID = (Guid)user.ProviderUserKey;
 DL.SaveObject (Object, userID);

OR

Сделайте это в DataLayer: 

SaveObject(Object)
{ 

 MembershipUser user = Membership.GetUser();
                Guid userID = (Guid)user.ProviderUserKey;
 ...
 ...

}

Ответы [ 3 ]

2 голосов
/ 07 февраля 2009

Хотя это действительно междисциплинарная проблема, я лично предпочитаю такой код: 

MembershipUser user = Membership.GetUser();
Guid userID = (Guid)user.ProviderUserKey;

НЕ должно быть на уровне данных.

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

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

2 голосов
/ 07 февраля 2009

Передача ввода в DataAccessLayer должна выполняться контроллером или BL. Я предпочитаю не включать в DAL ничего кроме чтения / записи данных. (в этом случае DAL задается задача определения текущего пользователя, вошедшего в систему)

1 голос
/ 07 февраля 2009

В целом, я бы предпочел видеть GetUser () в SaveObject (), так как это позволило бы абстрагироваться от бизнес-уровня и уменьшить количество кода, вызывающего GetUser (). Но это зависит от требований. Если вам необходимо применять бизнес-правила, основанные на том, кем является пользователь, то (также) может иметь смысл ввести их в бизнес-уровень.

Авторизация / аутентификация - одна из тех сквозных проблем, с которыми AOP (аспектно-ориентированное программирование) лучше всего подходит.

Обновление: CraigTP делает правильную точку, в которой уровень данных не зависит от того, откуда берутся данные. В целом я бы согласился. В этом сценарии существует требование, когда механизм персистентности данных требует идентификации пользователя, вероятно, для целей безопасности и / или аудита. Поэтому в этом случае я бы предпочел поставить вызов доступа к идентификатору пользователя под контроль уровня, который нуждается в нем. Я бы абстрагировал детали реализации GetUser () от другого вызова, чтобы уровень данных не зависел от System.Web.Security.

...