Dobre praktyki

Cześć,
Mam parę pytań które mnie nurtują:

1. Jak podchodzicie do blokowania/ukrywania przycisków na UI , tak aby zawsze akcja była dozwolona tylko gdy dany obiekt jest w określonym stanie, załóżmy że te stany są obliczane skomplikowaną logiką. Osobiście wydzieliłem logikę biznesową do osobnej klasy służącą do sprawdzenia czy można wykonać daną akcje na obiekcie. Używana jest ona do ukrycia przycisków po stronie UI poprzez Razor, flagi dla skryptów js wrzucamy do hidden field'ów, używamy jquery, więc tam też są if'y. W starszych modułach cześć logiki jest sprawdzana na bazie czy jest w dobrym stanie oraz osobnymi if'ami na UI.
   Więc klasa która jest używana do akcji ma np 4 metody, a klasa sprawdzająca czy można wywołać akcje 2x4 metody ( dla UI bez out z errorem jako string ) + bardziej ogólne metody czy użytkownik ma prawa aby zobaczyć ten przycisk ( używane do wrzucenia w hidden field'y dla js).
   Może są jakieś lepsze praktyki?

2. Załóżmy że jeden klient chce aby pewien proces biznesowy wyglądał trochę inaczej np coś obliczał albo pomijał jakiś krok. Dodajecie if'a czy próbujecie to rozegrać przez kompozycje, np wstrzykiwać inna klasę zależnie od potrzeby?

3. Mam x klas które służą do wykonywania jakieś logiki biznesowej lub jako warstwa dostępu do bazy wszędzie są dodane interfejsy ale nie widzę w tym przypadku wartości tego interfejsu, kiedy stosujecie interfejs, czy tylko jak widać kilka możliwości implementacji jakiś metod, czy dodajecie prewencyjnie, czy może później wyciągacie?

Ad 1: Nie wiem czy dobrze rozumiem. Jest sobie jakiś obiekt biznesowy, który może mieć stany - więc to maszyna stanów, najlogiczniej takie stany trzymać jako enum. Kontroler pyta obiekt biznesowy o jego stan i na tej podstawie generuje viewmodel. Ten z kolei może np. zawierać pola: IsButtonActive, IsButtonBVisible, itd. Na podstawie tych pól Razor generuje odpowiednio widok (wstawia odpowiednie style).
Nie bardzo tylko rozumiem do czego tu JS służy.

Ad 2: No jeśli jest tam jakiś workflow, to ja bym sobie zaimplementował go jako ciąg klas reprezentujących poszczególne kroki, każda z nich miałaby metodę public WorkflowState Process(WorkflowState input) i dzięki temu można byłoby te kroki ustawiać w dowolnej kolejności.

Ad 3: Nic dziwnego, że nie widzisz wartości, tworzenie interfejsów do każdej klasy to jakaś bzdura. Interfejsy mają sens po pierwsze jako budulec wzorców projektowych, po drugie w przypadku klas, które wykonują jakieś potencjalnie czasochłonne operacje, które nie są pod Twoją kontrolą, czyli np. wysyłają dane do zewnętrznego serwisu webowego. Posiadanie interfejsu dla takiej klasy umożliwia mockowanie i napisanie testów jednostkowych do Twojego kodu.