2009-12-27 3 views
1

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

EG:

Пользователь запускает программу - Войти требуется

Пользователь хочет просматривать зашифрованные данные - подтверждение пароля требуется

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

Так что было бы хорошим способом реализовать это?

Любые предложения приветствуются?

ответ

1

Возможно, это не простейшее решение для реализации, но вы можете изучить использование Aspect Oriented Programming. Затем вы можете аннотировать каждый метод, который требует входа пользователя в систему. Это делает код чистым и читаемым.

[ConfirmUser(ErrorMethod=... RequireUsername=false, RequirePassword=true)] 
public void ViewData() 
{ 
    // your code 
} 

Структура AOP будет сплетаться в требуемом коде для обработки подтверждения пользователя в вашем методе.

Или сделать то же самое внутри методов вручную:

public void ViewData() 
{ 
    ConfirmUser(); 
    // your code 
} 

public void ConfirmUser() 
{ 
    if(!DoLoginPage()) throw new SecurityException("Incorrect credentials"); 
} 

Вы могли бы ConfirmUser возвращать логическое значение вместо исключения. Это еще одно обсуждение и зависит от вашего приложения. Если вы отказываетесь от операций в более низких слоях кода, исключение - путь. Попробуйте/поймать, чтобы вы поместили обработку ошибок в нижней части функции, в то время как возвращаемый bool требует и если оператор сверху.

public void ViewData() 
{ 
    try 
    { 
    ConfirmUser(); 
    // your code 
    } 
    catch(SecurityException) 
    { 
    //handle error 
    } 
} 

против

public void ViewData() 
{ 
    if(!ConfirmUser()) 
    { 
     //handle error 
     return; 
    } 
    // your code 
} 

Вы могли бы реализовать как ConfirmUser и ConfirmPassword, или оба в тот же метод с параметром, возможно перечисление сказать, что вам нужно проверить.

[Flags] 
public enum Requires 
{ 
    Username, 
    Password 
} 

public bool ConfirmUser(Requires requiresField) 
{ 
} 
1

Одним из подходов может быть создание «аутентифицированного пользователем» метода.

Так что, когда когда-либо вам нужно проверить, что пользователь может выполнить требуемое действие вы делаете вызов:

if (UserAuthenticated()) 
{ 
    // Perform action 
} 

Этот метод держать детали пользователя и ввести пароль и проверить их на базы данных. Если детали совпадают, верните true и продолжайте.

При запуске имя пользователя не будет установлено, поэтому диалог также может запросить об этом.

Это пример aspect orientated programming или cross-cutting concerns.

0

Вообще говоря, нет никакой реальной разницы в разработке многоразовых форм по сравнению с проектированием любого другого многоразового класса - поместите классы, которые вы хотите повторно использовать в одну или несколько сборок, и ссылайтесь на них с того места, где вы хотите их повторно использовать , Это работает как для форм, так и для любого другого многоразового класса.

Если вам нужна небольшая разница в функциональности вашей Формы в зависимости от контекста, который вы вызываете, вы можете, например, написать соответствующие конструкторы или инициализировать диалог соответствующими методами, прежде чем показывать его.

Смежные вопросы