POCO + Entity Framework с шаблоном хранилища - обработка разрешений - PullRequest
Новая
       31

POCO + Entity Framework с шаблоном хранилища - обработка разрешений

3 голосов
/ 23 августа 2010

У меня есть приложение, которое состоит из 3 уровней:
UI : для реализации в ASP.NET MVC
Business : содержит бизнес-логику и доступ к ресурсамcontrol
Репозиторий (DAL) : Реализован с объектами POCO и EF с использованием шаблона репозитория.Мои объекты POCO используются совместно с верхними уровнями.

У меня есть вопросы о том, какую информацию / методы должны иметь POCO?То есть: если у меня есть таблица User, которая содержит имя пользователя и пароль для пользователя, что должен иметь мой POCO?Как мне проверить пароль?Должны ли мои POCO иметь метод, который запрашивает хранилище для проверки?

Кроме того, как я должен контролировать доступ к своим ресурсам?Должны ли мои репозитории контролировать, кто может и не может получить доступ к ресурсу?Это все еще позволяет моим POCO предоставлять информацию со свойствами навигации.Должен ли я проверить в POCO propoertise, если текущий пользователь может использовать их тоже?

Заранее спасибо.

Ответы [ 3 ]

1 голос
/ 23 августа 2010

У меня есть похожий проект, и я могу дать вам некоторые подробности о том, как я выполнял подобные операции. Я предполагаю, что все ваше решение основано на .Net.

POCO (простые старые объекты CLR) - это просто объекты без бизнес-логики. Таким образом, проверка паролей должна осуществляться не непосредственно в этом классе, а на вашем бизнес-уровне. Например, пользовательский интерфейс будет вызывать действие контроллера для отправки данных на бизнес-уровень (BL), BL будет выполнять проверку пароля пользователя, вызывая хранилище для получения текущего сохраненного / зашифрованного пароля, BL будет сравнивать пароли и возвращать привести к вашему интерфейсу или предпринять какие-либо другие действия. Конечно, все данные также должны быть проверены, чтобы предотвратить такие вещи, как внедрение SQL или атаки межсайтового скриптинга.

Ваш POCO может иметь свойства Uid / Pwd. Вы должны передавать этот объект POCO между слоями приложения. Таким образом, пользовательский интерфейс MVC будет привязан к вашему пользовательскому объекту, и при отправке контроллер вызовет некоторый метод в вашем BL и выполнит бизнес-правила (пароль действителен) для этого пользовательского объекта. Чтобы передать их между фактическими слоями, вам нужно извлечь эти POCO из основного DAL и поместить их в отдельную сборку. Эти объекты обычно называют доменными объектами, и вы можете воспользоваться разработкой Google Domain Driven, чтобы получить больше информации об этой методологии.

Безопасность может быть реализована несколькими различными способами в приложении, все зависит от глубины элементов, которые вы хотите охватить. Основным в MVC является использование атрибута Authorize на ваших классах контроллеров (Google: Защита ваших действий контроллера). Когда ваш пользователь проходит проверку подлинности, ему могут быть назначены некоторые типы ролей приложений, и вы можете проверить, имеет ли пользователь одну из этих ролей, используя следующий формат: 

[Authorize(Roles = "ModifyUserRoles")]
        public ActionResult About()
        {
}
0 голосов
/ 30 августа 2010

Я думаю, что не всегда необходимо передавать ваш объект POCO (объект домена) через слои, например, в вашей ситуации для слоя View требуется только простая модель представления с только свойствами имени пользователя и пароля и она передается в BL Это ваш BL, который получит объект домена пользователя через репозиторий и проверит пароль на соответствие тому, что он получил от слоя просмотра.

0 голосов
/ 23 августа 2010

Если ваш контекст возвращает объект пользователя, оператор select "подтвердит" пароль: 

public User GetUser(string login, string password)
{
//...code to set up context var...
var user = (from o in context.Users.OfType<User>() where o.UserID == login && o.Password == password) select o).FirstOrDefault();
//...maybe more code...
}

Ваш бизнес-уровень должен решать, как зашифровать пароль и как обработать неудачный вход в систему (метод возвращает ноль).

Лично я не думаю, что какая-либо бизнес-логика должна быть в вашем DAL. Определение того, кто имеет доступ к функции, которая лучше всего выполняется на бизнес-уровне, но вы можете отключить отложенную загрузку и включить свойства навигации только на основе пользователя ИЛИ вы можете сделать дополнительный запрос для этих свойств, когда они необходимы. Количество и тип возвращаемых данных (по соображениям производительности) будут определять это решение.

...