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

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, пользовательские идентификаторы и т. Д. Отступая от всего этого, заставляя мой домен получать достаточно умный, чтобы решить, что можно увидеть и сделать, поэтому нет смысла дублировать это в клиенте пользовательского интерфейса.

Итак ... да. Все еще имеют нулевые проблемы с this approach. Ничего не изменилось в течение ~ 4 месяцев.
Работает как очарование.