Поставщик членства из уровня обслуживания - PullRequest
Новая
       17

Поставщик членства из уровня обслуживания

4 голосов
/ 15 ноября 2011

В практических целях я собираюсь создать новое приложение ASP.NET MVC 3.0. Мое решение (Practice.sln) будет иметь 4 слоя:

  • Pratice.Common (библиотека классов для моих ViewModels)
  • Pratice.Data (библиотека классов для EF)
  • Pratice.Service (библиотека классов для бизнес-логики)
  • Pratice.Web (проект asp.net mvc 3.0)

Давайте предположим, что у меня есть представление под названием «Логин», которое строго типизировано на LoginModel, определенной в моем слое Practice.Common. Модель LoginModel имеет 2 свойства (имя пользователя и пароль).

В моем контроллере, когда пользователь отправляет форму, я вызываю следующий метод: 

[HttpPost]
public ActionResult Login(LoginModel model)
{
    if(_service.ValidateUser(model))
    return null;
}

ValidateUser () - это метод, определенный в моем слое Pratice.Service (внутри моего файла LoginService.cs).

Я в основном делегирую процесс проверки моему уровню обслуживания ...

У меня следующий вопрос:

Учитывая, что я хотел бы попробовать / использовать преимущества поставщика членства, и учитывая, что большая часть (если не вся) моя логика происходит на моем уровне обслуживания, как может переместиться Членство в мой уровень обслуживания ? (если это даже хорошо)

Кроме того ... Я планировал создать свой собственный провайдер членства, а не встроенный, поскольку я не использую все эти генераторы ТАБЛИЦ и спроков ...

Бонусный вопрос:

Считается ли наилучшей практикой, чтобы все управление учетными записями и учетными записями происходило непосредственно из вашего контроллера, а вся остальная часть моей бизнес-логики хранилась внутри моего уровня обслуживания?

Мне любопытно, что за и против имеют "части" логики, происходящие непосредственно внутри контроллера, и другие "части", происходящие на уровне обслуживания.

Конечно, если у кого-то есть ссылка или статья, объясняющая это, я был бы признателен!

С уважением

1 Ответ

3 голосов
/ 30 ноября 2011

Хорошо, после нескольких испытаний и прочтения мне удалось ответить на мои собственные вопросы.

Что касается перемещения поставщика членства на мой уровень обслуживания (в моем случае), который не делаетв любом случае, поскольку мой уровень обслуживания теперь будет зависеть от System.Web.Security, и я этого не хочу.

Кроме того, я быстро понял, что перепутал две концепции.FormsAuthentication и Членство.Хотя они работают рука об руку, мне не нужны все методы, предоставляемые Членством.Поэтому мне не нужно ни создавать пользовательского поставщика членства, ни использовать встроенного.

Все, что мне нужно сделать, - это продолжать создавать свои методы в моем слое обслуживания (например, метод Login ()).), а затем вручную создайте FormsAuthenticationTicket, который я добавлю в cookie, а затем добавлю этот cookie в коллекцию cookie (в контроллере).

В качестве примечания я также понял, что только после того, как вы добавили куки в коллекцию куки, HttpContext.User.Identity.IsAuthenticated начинает возвращать TRUE.

Насколько далекоКак и в случае с моим бонусным вопросом, если не указано иное, я сохраню механизм входа (и проверки) на уровне обслуживания вместо того, чтобы иметь некоторую логику в контроллере и некоторую логику на уровне обслуживания.

...