WPF przy użyciu niestandardowych RoutedUICommands lub prostych procedur obsługi zdarzeń?

Question

Rozmawiałem dzisiaj z kimś o wyborze schematu projektowego do obsługi logiki w programie WPF i mając nadzieję, że społeczność SO może pomóc w dalszym doradztwie, aby ułatwić podjęcie decyzji. Jakie czynniki na korzyść poleceń przeważają nad niedogodnościami?

przygotowałem pełną sample wraz z kilkoma UML diagrams pierwszych dwóch z trzech podejść:

1. użytku Kliknij obsługi zdarzeń na przyciski i menu.
2. Użyj poleceń powiązanych w XAML.
3. Używaj poleceń związanych w kodzie, z XAML utrzymywanym dla czystego układu GUI i stylizacji.

Kurs wprowadzający, w którym był i wiele książek pokazuje proste procedury obsługi zdarzeń Click jako naturalny sposób łączenia logiki z obiektami interfejsu użytkownika.

Był nieco zaskoczony ilością napowietrznych wymagane do korzystania z poleceń zarówno komendy tworzony w kodzie za akt:

public static readonly ICommand cmdShow2 = new RoutedUICommand(
    "Show Window2", "cmdShow2", 
    typeof(TestDespatchWindow)); 

a potem jeszcze kod w XAML z rozwlekły sposób komenda musi zostać zidentyfikowany i związany:

<Window x:Class="WPFDispatchDemo.TestDespatchWindow" 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    xmlns:w="clr-namespace:WPFDispatchDemo"..> 

    <Window.CommandBindings> 
     <CommandBinding Command="{x:Static w:TestDespatchWindow.cmdShow2}" 
     Executed="OnShow2" /> 
    </Window.CommandBindings> 
     <DockPanel> 
     <StackPanel Margin="0,8,0,0"> 
      <Button x:Name="Show2EventBased" 
        Margin="10,2,10,2" 
        Click="OnShow2" 
        Content="Show2 via WPF Event"/> 
      <Button x:Name="Show2Command" 
        Command="{x:Static w:TestDespatchWindow.cmdShow2}" 
        Margin="10,2,10,2" 
        Content="Show2 via WPF"/> 
     </StackPanel> 
    </DockPanel> 
    </Window> 

mogę (jeszcze) nie uważać się za eksperta WPF więc może mam pomalowane rzeczy jak bardziej skomplikowane niż są w rzeczywistości, ale moje podejrzenie, że nie można uprościć rzeczy o wiele bardziej niż powyższe.

Edit:

znalazłem ciekawą 3-way comparison między DelegateCommand, RoutedCommand i zawodów.

Answer 1

Poleca ich wady i zalety, musisz wybrać w zależności od sytuacji, Gorąco polecam dokonać tego wyboru w oparciu o przypadek, nie wybieraj "jedynej prawdziwej drogi" dla całego projektu.

Dla niektórych przypadkach separacja między nadawcą a odbiorcą oraz zdolność do wysyłania poleceń przy użyciu tylko XAML jest dużą zaletą (dla dobrego przykładu wyglądać jak szablon kontrola ScrollBar komunikuje się z logiką sterowania w http://msdn.microsoft.com/en-us/library/ms742173.aspx).

W innych przypadkach polecenia mogą zmienić to, co byłoby dwuliniowym programem obsługi zdarzeń w niemożliwe do naśladowania potworności polegające na zmianie 4 oddzielnych miejsc w aplikacji (How should the ViewModel close the form?).

Answer 2

Jedynym powodem jest posiadanie dobrze znanego rejestru poleceń. Oznacza, że ​​wydarzenia te mogą być prywatnymi metodami i czuję, że są ściśle związane z kodem okna. Jednocześnie polecenia pozwalają zachować implementację (zdarzenie) i definicję (polecenie) oddzielnie, możesz nawet użyć innej klasy (zajrzyj do ApplicationCommands).

Ponadto, gdy wykonuję swoją pracę WPF, używam implementacji ICommand (Command Pattern). Cała logika polecenia przechodzi do metody Execute. Pomaga mi to zachować separację logiki w bardziej uporządkowany sposób bez nadmiernej komplikacji kodu okna. Dzięki tej opcji możesz tworzyć polecenia na swoim modelu, a tym samym wiązać je z hałasem. Spójrz.

Utwórz model.

public class Model 
{ 
    ICommand CloseMessagePopupCommand {get; set;} 
} 

Następnie przypisz kontekstu danych

public MainWindow() 
{ 

    this.DataContext = new Model(); 
} 

i użyć kodu follwing XAML.

<Button 
    Command="{Binding CloseMessagePopupCommand}" 
    Content="{StaticResource Misc.Ok}" /> 

Answer 3

staram się pozostać wiernym wzorca polecenia, który odnosi się do Mike podczas tworzenia aplikacji WPF, używając kombinacji Andy'ego # 2 i # 3 podejścia.

Mogę myśleć o jednym minusie poleceń w moim widoku: tylko niektóre akcje niektórych elementów interfejsu wywołują polecenia. Jednym ze sposobów obejścia tego problemu jest wywołanie przez procedurę obsługi zdarzenia wywołania metody Execute w poleceniu. Myślę, że polecenia zapewniają bardzo dobry sposób enkapsulacji logiki wykonania. Jeśli utrzymujesz duży fragment interfejsu użytkownika i implementujesz go za pomocą wzorca MVC/MVC/MVVM, staje się to bardzo widoczne.

Zachęcam do zapoznania się z serią Dan Crevier na temat wzoru DataModel-View-ViewModel, w szczególności z sekcją o Poleceniach i Komendach enkapsulacji. Nawet jeśli ten wzór nie spełnia twoich potrzeb, daje świetny przegląd tego, jak możesz zamknąć logikę w oddzielnej klasie.

Answer 4

Inne wariacje na temat ICommand wydają się być popularnym sposobem wdrażania złożonych struktur poleceń.

Brian Noyes w Jego article on PRISM mówi

poleceń poprowadzone w WPF są bardzo wydajne i użyteczne, ale mają pewne braki, gdy stosuje się do złożonego wniosku. Pierwszym z nich jest to, że są one w całości powiązane z drzewem wizualnym - wywoływacz musi być częścią wizualnego drzewa, a powiązanie polecenia musi być powiązane przez drzewo wizualne. ... Drugą wadą jest to, że są one ściśle związane z drzewem skupień interfejsu użytkownika UI i kontynuują rozmowę o poleceniach DelegateCommand i CompositeCommand, które obejmuje CAL (Prism).