Po co mieć minimalny kod użytkownika / odręczny i robić wszystko w XAML?

Wydaje mi się, że społeczność MVVM stała się nadgorliwa, podobnie jak programiści OO w latach 90. - to myląca nazwa MVVM jest synonimem bez kodu. Z mojego zamkniętego pytania StackOverflow :

Wiele razy natrafiam tutaj na posty o kimś, kto próbuje zrobić ekwiwalent w XAML zamiast kodu z tyłu. Ich jedynym powodem jest to, że chcą utrzymać swój kod w czystości. Popraw mnie, jeśli się mylę, ale nie jest tak, że:

XAML jest również kompilowany - do BAML - wtedy w czasie wykonywania i tak musi zostać przeanalizowany w kodzie. XAML może potencjalnie zawierać więcej błędów w środowisku wykonawczym, ponieważ nie zostaną wykryte przez kompilator w czasie kompilacji - z nieprawidłowych pisowni - te błędy są również trudniejsze do debugowania. Za tym stoi już kod - lubię go lub nie InitializeComponent (); musi zostać uruchomiony, a plik .gics, w którym się znajduje, zawiera sporo kodu, choć może być ukryty. Czy to czysto psychologiczne? Podejrzewam, że to programiści wywodzą się z tła sieci i lubią znaczniki w przeciwieństwie do kodu.

EDYCJA: Nie proponuję kodu zamiast XAML - używam obu - wolę też tworzyć wiązania w XAML - Jestem po prostu przeciwny wszelkim wysiłkom, aby unikać pisania kodu za esp w aplikacji WPF - powinno to być połączenie oba, aby uzyskać jak najwięcej z tego.

AKTUALIZACJA: To nawet nie jest pomysł Microsoftu, każdy przykład w MSDN pokazuje, jak możesz to zrobić w obu przypadkach.

Nigdy nie słyszałem o nikim, kto sugerowałby umieszczenie wszystkiego w XAML.

W rzeczywistości byłby to okropny pomysł, IMO.

Problem historycznie wynikał z tego, że aplikacje Winforms posiadające logikę w swoim kodzie, która tam nie istniała, ponieważ była to logika . Stąd bierze się znaczenie VM. Umożliwia izolowanie części łączących widok z modelem.

Dlatego widok pozostaje do obsługi tylko tego, co działa najlepiej, czyli interfejsu użytkownika.

Teraz, jeśli zdarzają się sytuacje, w których interfejs użytkownika wymaga kodu, to i tak weź go i włóż do kodu. Powiedziałbym jednak, że w 95% scenariuszy najprawdopodobniej lepiej zostawić interfejs użytkownika w pliku znaczników, a jeśli potrzebujesz trochę kodu, prawdopodobnie pewną logikę próbujesz napisać to bardziej odpowiednio pozostawiono View Model. Wyjątkiem są rzeczy takie jak Zachowania, ale są one całkowicie osobnymi zwierzętami i wymagają specjalnego miejsca (tzn. Nie ma ich w kodzie).

Aby bezpośrednio odpowiedzieć na twoje pytanie i zakładając, że kiedy mówisz „kod”, że w każdym przypadku odnosi się to konkretnie do kodu (kod znajdujący się w klasie kontroli wizualnej), powodem jest to, że interfejs użytkownika można całkowicie zaimplementować i zmanipulowane w Blend przy użyciu tylko jednej technologii. Zakładamy, że twoi projektanci UX nie są programistami i nie chcą pracować w kodzie, i że są ekspertami od układu i XAML, a nie od programistów. Jeśli zaimplementujesz wszystko bez kodu, możesz dać takim projektantom narzędzia, których potrzebują do pracy w całości w swoim języku.

Zapewnia czysty rozdział między programowaniem imperatywnym a projektowaniem deklaratywnym.

Jest to główny powód istnienia „zachowań” w programach Silverlight i WPF - zamiast wkładać kod do kodu źródłowego, uczyń zachowanie jego własnym małym modułem wielokrotnego użytku. Jeśli to zrobisz, Blend daje tę korzyść, że dosłownie jest w stanie przeciągnąć i upuścić na kontrolkę. Teraz, zamiast mieć jakąś jednorazową ruchomą część do kontrolki XAML, wyodrębniłeś ruchome części do ładnego pojemnika, którym można manipulować za pomocą narzędzi projektantów.

Z mojego doświadczenia wynika, że ​​często sprowadza się to do próby użycia skomplikowanej logiki w wyzwalaczach XAML, aby nie dopuścić do tego, by kod pozostawał w tyle, gdy lepszym, prostszym podejściem byłoby umieszczenie tej logiki w żadnym z nich - należy to do widoku -Model.

Jedną z największych zalet robienia wszystkiego, co możesz w Xaml, jest to, że utrzymuje wszystkie zachowania w jednym miejscu. Za każdym razem, gdy programista musi przeskakiwać między xaml a kodem, trudniej jest go zrozumieć.

Byłem w zespole WPF, który nie uczynił redukcji kodu za priorytet. Kilkakrotnie zdarzało się, że debugowanie było znacznie trudniejsze, ponieważ jakiś program obsługi zdarzeń manipulował formantem i nie było to od razu widoczne, ponieważ zachowanie zostało rozproszone w dwóch plikach.

To powiedziawszy, uważam, że masz rację sądząc, że czasem lepiej jest pójść na kompromis w sprawie zasady projektowania. Niektóre rzeczy są bardzo trudne do zrobienia w Xaml. Spędziłem godziny, a nawet dni, próbując uzyskać zachowanie do pracy w Xaml, które mogłem zrobić w znacznie krótszym czasie, stosując kodowanie. Zacząłem traktować kodowanie jako ostateczność, ale nigdy nie powiedziałbym komuś, że nigdy nie powinien go używać. To kolejny kompromis, który musi zrozumieć dobry inżynier.

edycja: Z komentarzy wynika, że ​​mój post jest interpretowany jako argument przeciwko Xamlowi. Moim zamiarem było argumentowanie przeciwnie. Czysty xaml jest zawsze lepszy, ponieważ utrzymuje wszystkie zachowania w jednym miejscu. Mieszanka xaml i kodu z tyłu może się skomplikować, więc minimalizacja kodu z tyłu jest idealna. Xaml jest lepszy niż czysty kod z wielu powodów. WPF i Silverlight są zaprojektowane do pisania w xaml.

Mam tylko bardzo powierzchowną znajomość XAML, ale dziwi mnie, że kompilator nie wykryje literówek.

Podstawowa różnica polega na tym, że XAML jest deklaratywny , podczas gdy na przykład C # jest konieczny.

Po prostu:

Pane p = new Pane(200, 100);
Button foo = new Button("foo");
Button bar = new Button("bar");
p.addChild(foo);
p.addChild(bar);

vs.

<Pane width="200" height="100">
    <Button label="foo"/>
    <Button label="bar"/>
<Pane>

Górny kod naprawdę tworzy hierarchię na podstawie efektów ubocznych, podczas gdy dolny po prostu go deklaruje. Warto również zauważyć, że chociaż na przykład addChildmożna zmienić nazwę metody, relacja dziecko-rodzic jest rdzeniem modelu semantycznego i jako taka jest reprezentowana we fragmencie deklaratywnym. Jest bardzo daleki od implementacji, która pozwala na wiele optymalizacji pod spodem, takich jak leniwa instancja, całkowicie transparentnie.
Programowanie deklaratywne ma wiele zalet. Jest bardziej zwięzły, wyrazisty i bardzo zbliżony do twojego modelu. Poszedłbym tak daleko, jak to jest lepsze.

Nie oznacza to jednak, że powinieneś spróbować wbić wszystko w XAML. C # ma wiele konstrukcji wysokiego poziomu, które pozwalają na deklaratywny styl.

W końcu chcesz, aby Twój kod był krótki i łatwy do odczytania. Więc jeśli możesz osiągnąć to samo w C # przy mniejszym kodzie niż w XAML, użycie C # jest logiczne. Należy jednak pamiętać, że kod XAML jest bardziej „przenośny” w tym sensie, że jest znacznie mniej podatny na zmiany w używanych komponentach, abstrahując od struktury .NET (na przykład szczegóły implementacji powiązań).