Autoryzacja elementów interfejsu użytkownika w .NET WinForms

Question

Mam ogólne pytanie o najlepsze podejście do autoryzacji elementów interfejsu użytkownika dla ról aplikacji. Mam na myśli to, że Administrator widzi przyciski, pozycje menu itp., Których zwykły Użytkownik nie widzi. Jaka jest najlepsza praktyka w tym zakresie?

Zdaję sobie sprawę, że może istnieć wiele ekranów opartych na rolach (ekran administracyjny, ten sam ekran powielony dla użytkownika itp.), Co zdecydowanie wydaje się przesadą. Chcę również zachować separację problemów, aby mój kod autoryzacji nie był wymieszany z funkcją wyświetlania. Innymi słowy, chcę uniknąć:

if(current_user.IsInRole("administrator")) 
    button.Enabled = true; 

czekałem na aspektach z PostSharp, co wydaje prawie dokładnie to, co chcę zrobić, ale nie wydaje się logicznie rozszerzyć do interfejsu użytkownika.

Jestem pewien, że czegoś mi brakuje, co to jest?

Dzięki -

Answer 1

Wydaje się prawdopodobne, że Twój kod zostanie ostatecznie stworzyć listę elementów interfejsu użytkownika, aby ukryć lub wykonać daną czynność na, a następnie wykonać te działania oparte na obecnym stanowisku. Coś w rodzaju kompilacji tej listy jest przede wszystkim tym, o co pyta użytkownik. Schematy AOP zdecydowanie pomagają w rozdzielaniu obaw, ale rozwiązanie homebrew nie byłoby niemożliwe. Myślę, że coś takiego:

• Załóż EnableForRoleAttribute z parametrem role.
• Zastanów się nad swoimi formami (ewentualnie za pomocą refleksji, aby znaleźć formularze, lub ewentualnie dostarczając je do swojego kodu bezpośrednio, lub nawet znajdując formularze ozdobione RoleVaryingAttribute swojego stworzenia).
• Zastanów się nad polami formularzy, filtrując dla instancji Control, następnie dla instancji Control z EnableForRoleAttribute.
• Teraz masz swoją listę! Ustaw Enabled na podstawie roli.

Powyższa lista punktowana jest specyficzne dla przykładu Enabled, głównie dlatego, że nie może wziąć atrybuty lambdy jak parametry :(. Można być bardziej elastyczny ze SetPropertyIfInRoleAttribute z parametrami role, propertyName i propertyValue. Lub jakikolwiek . budowa

Zasadniczo ramy AOP tej pracy łatwiejsze, a niektóre jak PostSharp się zdarzyć w czasie kompilacji zamiast wykonywania Ale homebrew rozwiązanie jest dość ważny zbyt