Question

Я создаю приложение, используя asp.net mvc, DI, IoC, TDD в качестве учебного упражнения.

Для доступа к данным я использую шаблон репозитория. Теперь я смотрю на членство и как это может работать с шаблоном хранилища. В настоящее время я использую репозиторий Linq to Sql, но не хочу быть привязанным к SQL Server для членства.

Во-вторых, я хочу разделить членство на несколько служб:

AuthenticationService - идентифицировать пользователя
AuthorizationService - что они могут сделать
PersonalizationService - профиль

Служба персонализации будет тем, что действительно определяет «клиента» в моем приложении, и каждый клиент будет иметь уникальный идентификатор / имя пользователя, которое связано с сервисом AuthenticationService - таким образом, позволяя мне использовать поставщика членства ASP.NET по умолчанию, мой или использовать что-то вроде Open ID.

Это хороший подход? Я не хочу изобретать велосипед, но эти важные части моего приложения будут следовать тем же шаблонам, что и остальные.

Спасибо Ben

Sky Sanders · Answer 1 · 15 февраля 2010

Посмотрите на службу RIA Authentication, Roles и Profiles s ... не нужно изобретать велосипед.

Ben Foster · Answer 2 · 16 февраля 2010

Если честно, добиться того, чего я хотел, было довольно простым процессом. Я еще не реализовал AuthorizationService, но это будет происходить по аналогичной схеме.

Мой сервис аутентификации довольно прост:

public interface IAuthenticationService
{
    bool IsValidLogin(string username, string password);
}

Будет метод CreateUser, но я этого еще не реализовал.

Создание службы аутентификации с использованием стандартного поставщика членства - простая задача:

public class AspNetAuthenticationService : IAuthenticationService
{
    public bool IsValidLogin(string username, string password)
    {
        return Membership.ValidateUser(username, password);
    }
}

Если я хочу заменить SqlMembershipProvider по умолчанию своим собственным, мне просто нужно изменить web.config. Чтобы поддерживать разные типы аутентификации (возможно, формы auth и open id), я могу просто создать действие контроллера для каждого и вызвать соответствующую реализацию IAuthenticationService.ValidateUser перед установкой файла cookie аутентификации.

Процесс аутентификации для идентификации "пользователя". Для получения «Клиента» я использую PersonalizationService. Интерфейс для этого снова довольно прост:

public interface IPersonalizationService {
    Customer GetCustomer(string username);
}

Это возвращает моего клиента (с адресами, прошлыми заказами - тем, что нам действительно важно) Метод GetCustomer создаст объект customer, если он не существует с переданным именем пользователя. Таким образом, при использовании стандартных форм авторизации клиент будет создан в любом случае при регистрации. Если используется что-то вроде OpenID, то при первом входе в систему будет создан объект customer, который будет связан с их именем пользователя OpenID (отсюда и причина отделения того, кто является «аутентифицированным» пользователем от «customer».

Этот процесс также хорошо работает для анонимной проверки, поскольку я могу создать объект клиента в памяти для "гостевых" клиентов и, наконец, сохранить его в базе данных, если они совершают покупку. В этом случае у меня нет пользователя (потому что он не прошел аутентификацию), но у меня есть клиент.

Я вполне доволен этой реализацией. Я думаю, что у меня будет собственный провайдер членства (поскольку это не так уж сложно), и я хотел бы использовать шаблон хранилища для доступа к данным. Заинтересованы услышать любые мнения / предложения по этому подходу.

Некоторые ресурсы, которые я использовал:

http://noahblu.wordpress.com/2009/02/19/custom-membershipprovider-using-repository-dependency-injection-pattern-magic/

http://davidhayden.com/blog/dave/archive/2007/10/11/CreateCustomMembershipProviderASPNETWebsiteSecurity.aspx

http://pbdj.sys -con.com / узел / 837990 / мобильный

http://mattwrock.com/post/2009/10/14/Implementing-custom-Membership-Provider-and-Role-Provider-for-Authinticating-ASPNET-MVC-Applications.aspx