POCO с новой идентификацией ASP.NET Identity и MVC 5.0 + на основе утверждений

С новой версией RT 2013 RTM и asp.net mvc 5.0 я решил попробовать несколько вещей...

Излишне говорить, что многое изменилось. Например, новый ASP.NET Identity является заменой старых Membership и (менее старых) SimpleMembership API.

Во всех предыдущих приложениях, которые я построил, у меня никогда не было возможности работать с Membership или с SimpleMembership. Ive всегда заканчивал тем, что создал свой собственный метод Login(), который преобразует представленный ViewModel в POCO (используя automapper), который, в свою очередь, будет использовать какой-то репозиторий для поиска пользователя и пароля.

Взамен я получил бы User POCO, который позже будет преобразован (с использованием automapper) в меньший UserSession POCO. Чем меньше UserSession будет размещаться в сеансе.

Конечно, я бы по-прежнему использовал FormsAuthentication для создания Encrypted Ticket и использовал FormsAuthentication.SignOut(), когда пользователь хотел выйти из системы.

Но я никогда полностью не воспользовался тем, что Membership (or SimpleMembership) мог предложить.

У меня никогда не было каких-то POCOs, которые использовали какой-то интерфейс, и мне не нужно было добавлять ссылку на библиотеки Microsoft внутри моей библиотеки классов POCO. Другими словами, у меня никогда не было сильной зависимости от чего-либо.

Мой вопрос следующий:

В примерах, которые я вижу, я вижу, что новая идентификация ASP.NET создает (сначала через код) некоторые таблицы и поля. Например, таблица AspNetUsers содержит поле Id как string. Конечно, я уверен, что есть способ преодолеть это и в конце концов увидеть примеры, но почему кто-нибудь NOT want to build pure POCO classes и будет полностью контролировать, что и как создаются вещи?

Если Im confused (который имеет высокую вероятность), может ли кто-нибудь объяснить, почему я хотел бы использовать новый API ASP.NET Identity (или, что более важно, использовать новый Microsoft.AspNet.Identity.EntityFramework) для создания моих таблиц?

Что такое Pros and Cons в желании использовать это, в отличие от стиля POCO?

Возможно, мне следует задавать этот вопрос по другому вопросу, но Im также пытается понять, как я могу принести пользу новой Identity, основанной на утверждениях, при использовании POCOs вместо Entities, сгенерированных с помощью идентификатора ASP.NET.

Не стесняйтесь указывать меня в правильном направлении для разъяснений.

Ответ 1

вы можете полностью создать свой собственный UserManager, который я не рекомендую, если у вас нет сильных знаний о том, как это работает. Вы можете обернуть существующий UserManager и заставить приложение использовать интерфейс или просто использовать его прямо и извлечь выгоду из что microsoft вложил в него. Если вам не нравится EF, вы можете создать свой собственный магазин для использования другой базы данных. новая идентификация ASP.NET достаточно расширяема, я согласен с тем, что это довольно сложно, если вы хотите полностью контролировать и настраивать все, но я рекомендую потратить время, чтобы понять большинство из них, чтобы вы могли выбрать, когда использовать или нет. достаточно времени, чтобы использовать существующий UserManager.

Ответ 2

Вы хотите, чтобы UserManager из Microsoft.AspNet.Identity выполнял вашу часть безопасности, поэтому вашим пользователям не нужно доверять, что вы можете правильно обрабатывать информацию о безопасности.

Identity.Framework - это всего лишь хранилище данных для материала Identity, вместо этого вы можете создать свой собственный магазин, если вы не хотите EF. Я создал тот, который просто хранит информацию непосредственно в XML файле. Но я всегда возвращаюсь к использованию Identity, потому что я не хочу разбираться в шифровании и следить за тем, чтобы я был в курсе дел в отделе безопасности.