SimpleMembership - кто-нибудь сделал его дружелюбным?

Ответ 1

Одна из мощных концепций SimpleMembership заключается в том, что вы можете настроить профиль пользователя в соответствии с потребностями вашего приложения, как обсуждаемым в этой статье. Например, вы можете добавить подтверждение электронной почты в процесс регистрации, для чего потребуется сохранить адрес электронной почты пользователя в профиле пользователя. В предыдущем управлении членством/ролью для ASP.NET это было очень уродливо, чтобы реализовать и добавленные свойства были сохранены в блобе. Тьфу!

Итак, что это имеет отношение к вашему вопросу о том, как сделать SimpleMembership n-level дружелюбным? Хотя я согласен с тем, что генерируемый шаблон не является дружественным n-ярусом, я бы также сказал, что большинство реальных приложений MVC любой сложности потребует настройки SimpleMembership, и поэтому в любом случае потребуется сделать уровень или уровень, характерный для требований приложения. С другой стороны, создание многоразового уровня для SimpleMembership было бы полезно только в самых основных приложениях MVC.

Лично я пришел к выводу, что то, что генерируется шаблоном Интернета в отношении SimpleMembership, почти всегда будет изменено. Как упоминается в первой статье о которой я упоминал, первая часть настройки избавляется от атрибута SimplemembershipInitialization, что является просто ленивым способом инициализации SimpleMembership в том случае, если разработчик не используя проверку подлинности форм. И часто вам нужно переместить DBC-текст, используемый SimpleMembership, в DBC-текст для остальной части вашего приложения. Профили пользователей часто тесно интегрированы с остальной частью домена приложения.

И поскольку мы находимся на уровне безопасности SoC и ASP.NET, я бы сказал, что ASP.NET никогда не очень хорош в этом. Для проверки подлинности форм вы используете атрибут Authorize на своих контроллерах и/или действиях, которые принимают роль в качестве параметра. Это заставляет разработчика приложения думать о дизайне безопасности при разработке домена приложения. Вы должны определить, какие роли у него будут иметь приложение, и не дай бог, чтобы они изменились позже, потому что теперь вам нужно пройти все эти атрибуты и соответствующим образом обновить их. Я начал использовать специальный атрибут authorize, который принимает в качестве параметров имя ресурса и тип операции (например: чтение, запись, выполнение...). Затем я могу отображать роли в ресурсах/операциях в базе данных, чтобы они могли легко меняться или даже позволяли администратору вносить изменения в то, как роли реализованы в приложении. Microsoft теперь использует тот же подход с ClaimsPrincipalPermissionAttribute, когда они включили WIF в .NET 4.5.

Обновлено 3/8/2013

Я создал проект с открытым исходным кодом на CodePlex под названием SimpleSecurity, который отделяет SimpleMembership от приложения MVC. Вы можете прочитать об этом здесь. Я все еще думаю, что разработчики, скорее всего, захотят изменить SimpleSecurity, но поскольку это с открытым исходным кодом, они могут. Мы увидим, если это то, что мы можем развивать, чтобы быть многоразовым и лучше SimpleMembership.

Ответ 2

Принятый ответ неправильный, то есть не N-Tier. Доступ к данным членства и бизнес-логике происходит на одном уровне. Просто потому, что код находится в другой сборке, это не значит, что он не находится на одном уровне.

Без какого-либо механизма транспорта на уровне доступа к данным это не N-уровень.

Решение состоит в наследовании и переопределении класса WebMatrix SimpleMembershipProvider, так что его вызовы доступа к данным могут выполняться на отдельном узле.

Я рекомендую использовать dotPeek для просмотра SimpleMembershipProvider, чтобы вы знали, что делать в своих переопределениях.

Ответ 3

Я думаю, что ваш вопрос больше связан с SoC, чем с архитектурой n-уровня (что больше касается физического разделения между слоями, как указано в @klatzib).

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

Обращаясь к вашему вопросу по-другому, запрещает ли SimpleMembershipProvider создавать SoC в дизайне приложения или даже n-уровневую архитектуру? Нет, нет. Шаблон MVC4 построен для простоты, но ActionFilter, используемый для инициализации провайдера, не является частью реализации членства, и вы можете инициализировать поставщика любым способом, который вы считаете нужным (я предпочитаю сделать этот вызов с DI контейнер factory). Фактически SimpleMembershipProvider как никакой прямой зависимости от EF вообще, так что да, возможно удалить ссылки на EF DbContext в вашем веб-приложении.

Ответ 4

Именно то, что я искал (почти). Просто жаль, что он не был привязан к сущностным фреймворкам, так как я надеялся получить решение n-tier Kevin, работающее с ORM ORG: (