2009-10-02 7 views
10

zbudowaliśmy dużych aplikacji w oparciu o Composite Application Biblioteki i MVVM korzystając Infragistics kontroli.Jakie są twoje doświadczenia z porzuceniem MVVM dla architektury WPF opartej na UserControl?

Aby zaoszczędzić czas i uprościć aplikację, złapaliśmy wymóg MVVM zezwalając na . Mamy obecnie żadnych Prezenterzy lub ViewModels i nasze poglądy stały się proste UserControls, które są tworzone tak:

BaseEditor.cs:

using System.Windows.Controls; 

namespace App 
{ 
    public class BaseEditor : UserControl 
    { 
     public string Title { get; set; } 
     public BaseEditor() 
     { 
      Title = "This was defined in the Base Editor."; 
      Loaded += new System.Windows.RoutedEventHandler(BaseEditor_Loaded); 
     } 

     void BaseEditor_Loaded(object sender, System.Windows.RoutedEventArgs e) 
     { 
      StackPanel sp = new StackPanel(); 
      TextBlock tb = new TextBlock(); 
      tb.Text = Title; 
      sp.Children.Add(tb); 
      this.Content = sp; 
     } 
    } 
} 

CustomerEditor.cs:

namespace App 
{ 
    public class CustomerEditor : BaseEditor 
    { 
     public CustomerEditor() 
     { 
      Title = "This was overwritten by the CustomerEditor."; 
     } 
    } 
} 

Window1.cs.xaml:

<Window x:Class="App.Window1" 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    xmlns:local="clr-namespace:App" 
    Title="Window1" Height="300" Width="300"> 
    <Grid> 
     <local:CustomerEditor/> 
    </Grid> 
</Window> 

Oprócz kwestii sprawdzalności i faktu, że „czuje się brudna” robi WPF tak, mam doświadczył tylko pozytywne skutki od tej decyzji, np:

  • możemy odziedziczyć naszą non-XAML UserControls od siebie
  • używamy tak dużo kodu, jak chcemy, który przyspiesza rozwój
  • dołączenie kontroli infragistic bezpośrednio do naszej klasy modelu pochodzących z serwisu internetowego wyjaśnione dziesiątki małych problemów wiążących mieliśmy z wiążących Infragistics do ObservableCol lections
  • nawet w prostej WPF, brak ObservableCollections sprawiają problemy jak not being able to create a simple Menu odejść
  • jesteśmy zastępując EventAggregator jeden po drugim z bezpośrednich wydarzeń wykorzystujących UserControls i kodu tyłu, który wyjaśni wszystkie rodzaje problemów z imprez

Czy ktoś inny robiący MVVM w WPF miał podobne doświadczenia? Czy w dłuższej perspektywie spotkałeś się z prawdziwymi problemami?

+1

Więc, gdzie umieścisz swoją logikę biznesową? –

+0

otrzymujemy dane z naszych usług na ESB, większość logiki biznesowej jest tam wykonywana –

Odpowiedz

35

możemy odziedziczyć nasze non-UserControls XAML od siebie

ja nie rozumiem. A co z MVVM wyklucza dziedziczenie?

używamy tyle kodu źródłowego, jak chcemy, która przyspiesza rozwój

Code-tył jest w porządku tak długo, jak jest to kod, który zajmuje się tym widokiem. to znaczy. nie logika biznesowa, którą chcesz przetestować. Rozdzielenie obaw i wszystkich.

Nadal możesz wykonywać MVVM, robiąc wszystko w kodzie - nawet w widoku. W MVVM nie chodzi o zero kodu. Chodzi o oddzielenie obaw i korzyści, które z tego czerpiesz. Jeśli nie masz potrzeby projektowania swoich widoków w Blend, to wszelkimi sposobami możesz zamanifestować wiele lub cały widok jako kod. Heck, nawet jeśli masz do musisz pracować w Blend, istnieje pewna ilość twojego widoku, które nadal może być zamanifestowane jako kod. Trzeba tylko ocenić kompromisy i podejmować świadome i świadome decyzje.

mocowania infragistic sterujących bezpośrednio na naszej klasie modelu pochodzących z usług internetowych wyjaśniona dziesiątki małych wiążących problemów mieliśmy z wiązania Infragistics do ObservableCollections

Kontrole Infragistics są bardzo słabe. Tam, powiedziałem to. Jeśli jest to opcja, nie używaj ich. Jeśli nie jest to opcja (i ja też byłem na tym stanowisku), możesz normalnie pracować nad wieloma problemami z dołączonymi zachowaniami i innymi technikami. To kłopot, tak, ale nie obwiniaj MVVM - winien Infragistics za stworzenie zestawu kontrolnego, który jest tak sprzeczny z platformą WPF.

nawet w prostej WPF, brak ObservableCollections sprawiają problemy, jak nie jest w stanie stworzyć proste menu odejść

Nie rozumiem ten punkt w ogóle. ObservableCollections są częścią WPF, a nie MVVM. I przeczytawszy twoje pytanie (znowu - odpowiedziałem na to niedługo po tym, jak je przesłałeś) powiedziałbym, że to tylko twoje niezrozumienie, jak działa WPF - w ogóle nie ma to nic wspólnego z MVVM.

jesteśmy zastępując EventAggregator jeden po drugim z wykorzystaniem bezpośrednich wydarzeń i UserControls za kod, który wyjaśni wszystkie rodzaje problemów ze zdarzeniami

odpowiednim narzędziem dla właściwej pracy. Jeśli możesz używać zdarzeń bezpośrednich, możesz to zrobić, niezależnie od tego, czy używasz MVVM, czy nie. MVVM w żaden sposób nie wymaga użycia wzorca agregatora zdarzeń, więc znowu twój punkt jest niejasny. Wzorzec agregatora zdarzeń może być używany w celu zapewnienia współpracy różnych komponentów w środowisku wykonawczym bez żadnych zależności podczas kompilacji. Korzystając ze standardowych zdarzeń CLR, tworzysz silne zależności między swoimi komponentami. Jeśli kiedykolwiek zechcesz ich użyć w izolacji, będziesz miał jedną dobrą okazję.

Podsumowując, nie ma to większego znaczenia w przypadku MVVM, ale raczej braku zrozumienia. Myślę, że płyniesz pod prąd i radzę ci przyjrzeć się MVVM. Nie jest to srebrna kula ani wzór uniwersalny, ale z pewnością pomoże stworzyć fantastyczną podstawę dla aplikacji WPF/SL, jeśli będzie używana prawidłowo.

+2

+1 punktów Event Aggregator. Widziałem wiele nieporozumień związanych z jego użyciem ... wiele osób sądzi, że podczas korzystania z MVVM + Prism * musisz * używać Agregatora zdarzeń do zgłaszania zdarzeń, gdy jest to po prostu nieprawda. –

+0

Muszę powiedzieć człowieka ... Przeczytałem to 10 razy. Świetnie spisuję się w jego komentarzach. Nie czytałem postu PO tak dokładnie jak ty ... naprawdę trafiłeś w każdy punkt. Bardzo dobrze. –

+1

Dzięki za tę długą odpowiedź, bardzo przydatne. Przyjrzę się MVVM bliżej, gdy miniemy nasze terminy, co pomaga nam osiągnąć stare, podobne do winform, sterowanie użytkownikami. A co z MVVM wyklucza dziedziczenie? Rozumiem widok jako UserControl z XAML i z kodem. Jeśli masz CustomerEditorView i EmployeeEditorView i zdajesz sobie sprawę, że mają podobne funkcje, które powinni odziedziczyć po BaseEditorView, nie możesz dziedziczyć XAML, jak tylko możesz mieć czysty kod UserControl, jak w powyższym kodzie. To była jedna wielka wygrana dla nas, kiedy przełączyliśmy się na przykład. –

7

Próbowałem tego i skończyło się powrotem do MVVM. Kończy się tym samym, wywołanym zdarzeniami, kodem spagetti, który zawsze pojawiał się w Windows Forms. Jeśli nigdy nie będę musiał zrobić kolejnego myLabel.Text = this.MyLabelText, będę szczęśliwy.

Nie zrozumcie mnie źle - MVVM jest trudniejsze do utrzymania, a ty naprawdę musisz znać WPF, aby go usunąć.

Tracisz dużo, nie używając go, w tym wiele możliwości użycia funkcji mieszania wyrazów do kształtowania elementów sterujących i obiektów DataTemplates.

3

Hej, cokolwiek działa dla ciebie. Zbyt łatwo jest o tym pamiętać. Moje aplikacje wsuwają się w kod spaghetti, chyba że zwracam dość ścisłą uwagę na rozłączenie obaw, ale to nie znaczy, że MVVM jest jedyną drogą. Jeśli masz aplikację, która działa i którą możesz zmienić bez zbędnych kaskadowych efektów ubocznych, to powiedziałabym, żebyś z nią poszedł.

Z całym szacunkiem nie zgodziłbym się (bez komentarza) z Andersonem Imesem w jednym punkcie: nie uważam, że MVVM jest trudny do utrzymania; Uważam to za bardzo łatwe. Dla mnie jest to najprostsze i najbardziej naturalne podejście do projektowania aplikacji WPF. Używam go w ramach Composite WPF (Prism), który zapewnia bardzo solidną strukturę partycjonowania złożonych aplikacji.

Napisałem CodeProject article o wdrażaniu MVVM w aplikacji świata rzeczywistego. Mamy nadzieję, że ludzie, którzy dopiero wchodzą do MVVM, uznają to za pomocne.

+3

Jeśli pochodzisz z WinForms, MVVM nie jest naturalny i ma bardziej stromą krzywą uczenia się, to wszystko, co mówię ... musisz Dowiedz się wiele o wiązaniu WPF, DataContexts, AttachedProperties, itp., aby naprawdę opłacić się dla Ciebie. –

+1

MVVM ma w sumie wiele sensu, być może po prostu próbowaliśmy za dużo zrobić z nim, tj. Tworzyć dynamiczne formularze oparte na XML z usług. Dzięki UserControls związanym z modelem mamy o wiele więcej kontroli. –

+1

Anderson - Tak, zgodziłbym się, że pochodząc z WinForms, MVVM może mieć krzywą uczenia się. MVVM jest o wiele łatwiejszy do nauczenia, jeśli masz doświadczenie WinForms z wzorcem Model-View-Controller, który ma wiele podobieństw do MVVM. –

1

Model widoku jest dobry, ponieważ ułatwia to utrwalanie danych. Databinding nie obejmuje wszystkiego, co musisz zrobić, więc kod dołączony do XAML jest wygodny.

Z mojego doświadczenia wynika, że ​​połączenie modelu widoku i dołączania do wydarzeń wydaje się wykonywać tę pracę, dopóki nie zostanie wypracowane bardziej czyste podejście, jeśli zajdzie taka potrzeba.

EDIT:

Mocowanie do wydarzeń niekoniecznie przełamać modelu MVVM jeśli używasz obsługi zdarzeń do przekazania zdarzenie do logiki procedury obsługi w viewmodel lub innej odpowiedzialnej obiektu.

Istnieją zalety czystego wiązania danych, ponieważ łatwiej można tworzyć różne skórki XAML, które używają tego samego mechanizmu wyświetlania. Jednym z przykładów jest posiadanie skóry do debugowania, która eksponuje niektóre wewnętrzne czynności, aby pomóc w rozwoju i działającej skórze, która jest produktem końcowym. Różne widoki XAML mogą wiązać się z tym samym modelem podglądu.

10

Zacząłem robić aplikacje WPF we wzorcu projektowym FFA (free-for-all), a ja nie wrócę, nawet w przypadku małych projektów. Chociaż wydaje się, że jesteś bardziej produktywny, kierując się prosto do źródła, na czysto metalowym interfejsie, doszedłem do wniosku, że jest to bardziej produktywność, ponieważ dostajesz natychmiastową gratyfikację.

Zastanów się: TextBlock.Text = "HelloWorld". Brak modelu ViewModel do skonstruowania, bez sklejania V i VM lub ustawień wiązania. Hit F5 i widzimy "HelloWorld" w całej okazałości. Mój problem z tym jest wielowymiarowy. Oto kilka z moich największych problemów:

  • Oddzielenie obawy. Bez niego nawigacja po kodzie, naprawianie błędów i rozbudowa jest poważnie utrudniona. Dodanie do aplikacji funkcji będzie o wiele bardziej podobna do książki przygodowej wybierania własnej przygody z lub ćwiczenia w fizyce kwantowej, niż to, że faktycznie coś robi. Jeśli masz przewidywalny sposób na zbudowanie aplikacji, masz przewidywalny sposób pracy nad nią.

    Elastyczność interfejsu użytkownika. Podczas używania wzorca FFA odkryłem, że moja zdolność do projektowania interfejsu użytkownika w moich aplikacjach była prawie niemożliwa. Zbyt wiele razy miałem kontrolę I nie można zaprojektować w Blend. Byłoby to po prostu dać czerwoną granicę z wyjątkiem wyjątku . W przypadku niektórych podanych kodów miałem użyć czegoś innego, co nie było przydatne w trybie projektowania, powodując problem z numerem .Przeprowadzka do MVVM magicznie naprawiła wszystkie moje problemy z mieszaniem. Jeśli otrzymam teraz czerwoną ramkę w Blend, I WIEDZAMY to jest problem z moim kodem prezentacji . Nic więcej.

Więc za pomocą FFA mogą uzyskać V1 za drzwiami szybkie, ale prywatni przedsiębiorcy będą się zastanawiać, dlaczego v1.5 zajmie cztery razy dłużej niż v1. Wszyscy byliśmy tam :)

Myślę, że jeśli chcesz zrobić coś takiego, pracowałbym z bezstresowymi kontrolkami, gdzie definiujesz UI "CZĘŚCI", czyniąc je bardzo Blendable. Otrzymasz odwołanie do formantów interfejsu użytkownika za pośrednictwem OnApplyTemplate. Te kontrole są w pełni odtwarzalne i dziedziczne. To Twój widok, w którym użyjesz tych elementów sterujących i wyciągniesz dane z wiązania, przekazując je do bezszelestnych kontrolek. Widok, IMO, zawsze powinien być klejem, aby VM wiązała się z takimi rodzajami kontroli.

W przypadku formantów Infragistics, z którymi masz problemy, zakładając, że korzystasz z Prism, powinieneś dla nich utworzyć niestandardowy adapter regionu. Dzięki temu możesz DOKŁADNIE napisać, w jaki sposób zostaną dodane kontrolki do Infragistics. Brak powiązania. Widok wtrysku będzie działał tak, jak przyzwyczaiłeś się do tego, kiedy już to zrobisz.

Widziałem, że niektórzy ludzie mają takie problemy w MVVM, ale uważam, że to po prostu zbytnie zajęcie MVVM. Nie wszystko zostaje zauważone przez posłańca. Moja ~ 40 widok (i rośnie) aplikacja ma około 5 złożonych wydarzeń. Kontrolę dziedziczę, używam wtrysku widoku do rzeczy, które nie są nawet panelami ani elementami kontroli treści. Czasami mam kod/zdarzenia związane z kodem związanym z prezentacją kodu ... I ... naprawdę, popieram MVVM i nie daję @ $ &% o testowaniu :)

+2

Chciałbym zobaczyć realistyczną aplikację demo wykonaną z MVVM (a nie taką, która robi prostą rzecz jak StockTrader), ale coś, co łączy się z bazą danych z pełną zdolnością crud, która używa infragystyki lub telerik lub jakiegoś realnego świata komponenty firm trzecich, które mają pewnego rodzaju skalowalność, np. kontrole są wprowadzane ponad granice projektu. Kiedy wszystkie te rzeczywiste aspekty wejdą w waszą aplikację, jeden z nich ma obowiązek wycofać się z MVVM, dobrze byłoby zobaczyć GDZIE wycofuje się i zobaczyć, jakie są kompromisy, ograniczone testy UI, itp. –

5

Nie zgadzam się z tym, Pracowałem nad aplikacją biznesową na dużą skalę, używając kontrolek WPF, MVVM, WCF i Telerik. Na początku korzystanie z MVVM było trochę trudne, ale gdy już uzgodniliśmy z naszym projektem i strukturą modelu View, stało się to bardzo łatwe. Możliwość ponownego użycia była bardzo łatwa do osiągnięcia, a czas opracowywania został również skrócony.

Co więcej, zmiana kontrolek była bardzo łatwa; w niektórych miejscach używaliśmy podstawowych kontrolek WPF, które później zastąpiliśmy kontrolkami telerik i na odwrót (jak w niektórych miejscach nie potrzebowaliśmy ciężkich sterowników teletekstowych, takich jak GridView). Mogę powiedzieć, że w razie potrzeby moglibyśmy łatwo zastąpić wszystkie elementy sterujące teleriksem innymi kontrolami stron trzecich lub natywnymi kontrolkami WPF w łatwy sposób w dowolnym momencie.

Ale tak, musieliśmy wprowadzić pewne obejścia podczas korzystania z kontroli teleriksem i napisać kod w kodzie, aby rozwiązać niektóre problemy (błędy w teleriksie); cały ten kod był czysto logiczną prezentacją.

2

Adwokaci MVVM ponad stan ich przypadku. Twierdzą, że alternatywą dla MVVM jest kod spaghetti. To, co Edward opisuje, wciąż podąża za wzorcem, to po prostu nie jest MVVM. Fakt, że widoki są powiązane z modelami, jest podobny do MVC. Kod z tyłu można uznać za kontroler.

Najwyraźniej uważa, że ​​wyniki są lepsze pod względem wysiłku rozwojowego i łatwości konserwacji. Ponieważ ta ostatnia jest jedyną słuszną przesłanką dla wzoru, sprawa przeciwko jego podejściu nie jest jasna.

Powiedzenie "nie rozumiesz MVVM" nie jest tak naprawdę argumentem przeciwko jego podejściu. Wzór łatwiejszy do zrozumienia jest lepszy niż taki, który nie jest.

+0

rekord, używam MVVM i wierzę, że to podejście jest czystsze i łatwiejsze w utrzymaniu. Przyznam, że trudniej jest poprawnie ustawić. – Gunnar

Powiązane problemy