Пользовательский провайдер членства и доменно-управляемый дизайн

Question

У меня есть проблема, когда я пишу пользовательский провайдер членства, но я не уверен , где поставить его.У меня нет никакого кода, чтобы показать вам, но в основном провайдеру нужен доступ к System.Web.Security для того, чтобы наследовать класс, но ему также нужен доступ к данным (то есть строка подключения + LINQ to SQL), чтобы сделать простойтакие задачи, как ValidateUser.

Как мне написать провайдера членства, который придерживается принципов DDD, о которых я читал в Pro ASP.NET MVC2 Framework от Apress?Моей единственной мыслью было написать другой класс в моем доменном проекте, который выполняет всю «работу», связанную с базами данных.По сути, я бы удвоил количество методов.Кроме того, может ли это работать с внедрением зависимостей (IoC)?

Надеюсь, что это не слишком общее ...

С нетерпением ждем ответов улья!

Редактировать: Я только что заметил, что в проекте MVC2 по умолчанию есть AccountController, который имеет обертку вокруг IMembershipService.Это мой ответ?Кажется, что AccountController не имеет компонента доступа к базе данных.

Answer 1

Функции управления пользователями Asp.net являются суперинвазивными.
У них даже база спама с таблицами профилей, а что нет.

Когда мне приходилось внедрять управление пользователями в моем приложении, я успешно избегал всей этой путаницы и все еще мог использовать встроенные роли asp.net, идентификационные данные пользователей и т. Д. Отойдя от всего этого, хотя мой домен становится умным достаточно, чтобы решить, что можно увидеть и сделать, поэтому нет смысла дублировать это в UI-клиенте.

Так что ... да. Все еще нет проблем с при таком подходе . Ничего не изменилось за ~ 4 месяца.
Работает как шарм.