Шаблоны дизайна провайдера в asp.net - PullRequest
Новая
       11

Шаблоны дизайна провайдера в asp.net

0 голосов
/ 15 января 2010

Мне нужна помощь с архитектурой DLL / шаблонами проектирования / OO.

Я изучал шаблоны проектирования фабрики классов как Решение моей нынешней проблемы и может использовать некоторые отзывы с этой точки зрения.

У меня есть три класса, которые являются пользовательскими оболочками для ASP.NET 2.0 ProfileProvider, MembershipProvider и RoleProvider.

Я хотел бы реализовать способ вызывать каждый, который разумно простой и понятный для разработчиков. Что-то с эффектом: 

Object obj = new Users().Permissions.CreateRole();
Object obj = = new Users().Membership.CreateUser();
Object obj = = new Users().Profile.GetUserProfile();

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

Есть какие-нибудь предложения относительно лучших практик относительно того, как начать? Или, что еще лучше, иллюстрации кода? :)

Ответы [ 2 ]

1 голос
/ 15 января 2010

API-интерфейсы для классов провайдеров членства довольно просты, и я не думаю, что их можно обернуть. Я думаю, что вы ищете фасадный рисунок . По сути, вы бы создали класс, который инкапсулирует действия по управлению пользователями для вашего приложения и скрывает внутреннюю реализацию. Звонки в класс могут выглядеть так: 

userService.CreateAdminUser("keith", "godchaux");

класс UserService будет использовать поставщика членства для создания нового пользователя и назначения ему роли администратора.

0 голосов
/ 15 января 2010

Мне кажется, что вы создаете абстракцию поверх абстракции без реальной цели и без реальной выгоды.У меня есть проблемы с тем, как были реализованы поставщики ASP.NET (для тестируемости), но я обратился к этому по-другому.

Я создал класс, который обернул элемент MembershipProvider и реализовал интерфейс.Все, что он делает, это передает вызовы методов в MembershipProvider, но он позволяет мне полагаться на интерфейс, а не на реализацию.В моих тестах я могу поменять IMembershipProvider на поддельную версию.

edit, пример кода:

IMembershipService 

// Membership service that just provides Create/Delete
public interface IMembershipService
{
    IMembershipUser CreateUser(string username, string password);
    void DeleteUser(string username);
}

и IMembershipUser 

// IMembershipUser that provides a lot of the necessary details
public interface IMembershipUser
{
    string UserName { get; }
    bool IsApproved { get; }
    bool IsLockedOut { get; }
    string Email { get; }
    DateTime LastLoginDate { get; }
    DateTime CreationDate { get; }
    bool ChangePassword(string oldPassword, string newPassword);
    string ResetPassword();
    Guid UserID { get; }
}

и простая оболочка для провайдера ASP.NET: 

public class MembershipWrapper : IMembershipFactory
{
    #region IMembership Members

    public IMembershipUser CreateUser(string email, string password)
    {
        var user = System.Web.Security.Membership.CreateUser(email, password, email);
        return new MembershipUserWrapper(user);
    }

    public void DeleteUser(string userName)
    {
        System.Web.Security.Membership.DeleteUser(userName);
    }

    #endregion
}

и MembershipUser 

    public class MembershipUserWrapper : IMembershipUser
{
    private MembershipUser _User;
    public MembershipUserWrapper(MembershipUser user)
    {
        _User = user;
    }
    #region IMembershipUser Members

    public string ResetPassword()
    {
        return _User.ResetPassword();
    }

    public bool ChangePassword(string oldPassword, string newPassword)
    {
        return _User.ChangePassword(oldPassword, newPassword);
    }

    public string UserName
    {
        get { return _User.UserName; }
    }

    public bool IsApproved
    {
        get { return _User.IsApproved; }
    }

    public bool IsLockedOut
    {
        get { return _User.IsLockedOut; }
    }

    public string Email
    {
        get { return _User.Email; }
    }

    public DateTime LastLoginDate
    {
        get { return _User.LastLoginDate; }
    }

    public DateTime CreationDate
    {
        get { return _User.CreationDate; }
    }

    public Guid UserID
    {
        get { return (Guid)_User.ProviderUserKey; }
    }

    #endregion
}

Очень простая реализация, но вы можете пойти в город с ней.

...