MVVM obrazac

Da zapocnem temu o MVVM obrascu gdje ce se nadam se podijeliti iskustva o njegovom koristenju u razvoju aplikacija.

Osobno mi se svidja kod njega sto za koristenje ne treba biti instaliran niti jedan framework ili toolkit, dovoljno je razumijeti kako se radi sa tim obrascem, a razvojna okolina (Silverlight u mojem slucaju jelte) vec ima sve spremno za njegovo koristenje: view.DataContext = new ViewModel();

Naravno, upotreba neke od brojnih biblioteka moze uvelike olaksati posao. Ja sam krenuo prvo sa MVVMLight, ali sam sada presao na Caliburn.Micro prvenstveno zbog "opinioned" pristupa, odnosno ugrađenih konvencija, i ViewModel-First pristupa. (PS moze se primjetiti kako .NETom sve više i više vladaju konvencije. Sve je bolje od XML konfiguracije!!)

Vaša iskustva?

Ja imam osobno nekoliko zahtjeva koje zelim da mi MVVM framework omoguci:

- automatsko spajanje View-a i ViewModela. Npr ako instanciram EmployeeViewModel, zelim da mi se automatski pokaze EmployeeView.xaml

- IoC/DI u konstruktoru VMa, preko MEFa, Unitya ili neceg treceg

- behaviori za bindanje evenata kontrola za metode VM-a

- automatsko bindanje nekih kontrola, npr: txtIme na public string Ime { get; set; }

- Messeging bus (event bus), ala mediator pattern (pisao o tome: http://www.hudosvibe.net/post/Slanje-poruka-unutar-Silverlight-aplikacije-pomocu-Mediator-patterna.aspx). Kada sam "otkrio" to, i maknuo tonu pretplata na evente, jako sam pojednostavio aplikaciju. Totalni must-have

- Caliburn.Micro ima sve ovo gore.

WCF, konverzija DTO sa automapper ili rucno, sve to standardno ide u paketu. Prije sam se dosta pridrzavao pravila kreiranje repozitorija, service layera za BLL, application layera sa web servisima, ali nikada nisam u biti vidio neku koristo od toga, samo nepotrebni layeri, a aplikacije nisu bile toliko velike. 

Sada se vise okrecem nekom pub/sub modelu rada cijele app: citanje podataka mora biti jednostavno, iz vec nekog denormaliziranog modela ili pomocu NH projekcija, ali bitno da se vrlo lako moze doci do podataka iz baze, bez komplikacija i 5 layera.

Zadatke vezane uz poslovnu logiku, nekakvo racunanje, poslovna pravila, upakiram u posebne klase (u service layeru recimo), koje pozivam preko pub/sub mehanizma - to se zovu komande. Npr imam AddProductToBasketCommandDTO koji sadrzi samo potrebne informacije (ProductID, UserID), a za tu komandu imam registriran handler. Kod buduceg skaliranja aplikacije lako je grupirati logiku, i primjeniti neki asinkroni messeging bus i SOA arhitekturu, a da se zadrze odlicne perfomanse (async queue).

U biti ovdje pricam o CQRS patternu... a jednog ljepog dana bi htio probati primjeniti i event sourcing pattern - totalna alternativa svemu sto sam radio do sada :) Jako pase u DDD, repozitorije, bounded context i sve one ljepe stvari o kojima Eric Evans prica u svojim knjigama.

Trenutno su mi SL aplikacije prepune slanja poruka (npr u VMu: Messenger.Publish(new SaveEmployee(data)), sto je dosta rasteretilo ViewModel klase. Pri startu aplikacije, automatski se potrebne BL klase pretplate na poruke (Messenger.Register<SaveEmployee>(this,employeeSaveMethod)), ili prođem sa refleksijom kroz cijeli assebmly, tražim određeni interface i registriram u centralni container handlera poruka. 

a jesam ga nadrobio ovdje svacega ;)

Pozdrav,

Pozivajući se na raspravu s twittera evo i mojih 5 centa na temu. :)

Od MVVM frameworka prije sam koristio prism dok danas koristim MVVMLight koji više manje zadovoljava sve moje potrebe. Caliburn.Micro sam isprobao no nisam ga koristio nigdje u produkciji.

Sama arhitektura prezentacijskog sloja sastoji se od sljedećih patterna:

• MVVM - očito :)
• ServiceLocator - prevenstveno mi služi za dohvat viewmodel objekata iz DI container-a.
• EventAggregator/MessageBus - komunikacijska kralježnica prezentacijskog sloja.
• Command  - Ako se radi o krajnje jednostavnim komandama koje se koriste samo na jednom mjestu, implementiram ih inline unutar viewmodel-a. S druge strane, ako se radi o složenijim komandama ili ako se komanda koristi na različitim mjestima implementaciju realiziram u zasebnoj klasi.
• Service Broker/Dispatcher - služi mi za koordinaciju komunikacije između servisa koji se nalaze na serveru i svih viewmodel objekata u aplikaciji. Upotrebom dispatcher objekta, osigurava se modularnost i labava povezanost na način da viewmodel klase ne moraju poznavati informacije o servisima koji služe za dohvat/spremanje podataka na serveru. Komunikacija se ostvaruje putem event aggregatora/messagebus-a.  Također, service dispatcher/broker je obično mjesto gdje stavljam keš prezentacijskog sloja.

U 95% slučajeva view bind-am na viewmodel unutar xamla. Iznimke su slučajevi kada želim određenoj funkcionalnosti view-a pristupiti u viewmodel-u. U tom slučaju, view implementira odgovarajući interfejs koji se inject-a u viewmodel čime zadržavam labavu povezanost između view i viewmodel klasa.

Kompleksna sučelja izbjegavam na način da ih odvojim u zasebne view/viewmodel klase(npr. AddressSearchBarView-AddressSearchBarViewModel

CoordinatesSearchBarView-CoordinatesSearchBarViewModel

SomeResultView-SomeResultViewModel

Na taj način eliminiram kompleksnost upravljanja korisničkim sučeljem.

U slučaju kada trebam omogućiti dodatnu logiku na kontrolama, koristim behaviour-e, kojima osiguravam dodatnu funkcionalnost.

Ako imam kompleksno sučelje ili nekakav kompleksni workflow, najčešće takvu logiku implementiram kao zasebnu kontrolu, gdje unutar kontrole upravljam izvođenjem, a expose-am samo one dependency property-e koji su mi potrebni za viewmodel.

Kao DI kontejnere sam koristio Unity i ninject.

Na serverskoj strani imam klasičnu arhitekturu podijeljenu u logičke/fizičke slojeve. S obzirom, da sam veliki štovatelj dijela i lika Eric Evans-a :), okosnicu serverske strane čini model. Unutar modela implementiram entitete, value objekte i specifikacije(linq je dosta eliminirao potrebu za istim). Svu funkcionalnost koja pripada modelu, implementiram unutar entiteta i value objekata kako ne bih imao anemičan model. Također, u modelu se nalaze interfejsi od repozitorija. Sama implementacija repozitorija nalazi se u DAL sloju u kojem najčešće koristim fluent nhibernate.  Iznad DAL sloja nalazi se fino granuliran BLL koji to sve drži na skupu. Klijent aplikacija se spaja na grubo granuliran servis koji je u principu remote facade za BLL.

S obzirom da je Silverlight rich client, često mi odgovara da punu funkcionalnost modela imam i na strani servera i klijenta. U tom slučaju, u zasebnom assembly-u se soft linkam na postojeći model na serveru čime izbjegavam repeticiju koda za istu logiku.

Malo van topica:

O CQRS-u sam puno čitao, gledao screencast-ve, i čini mi se kao odličan arhitekturalni pristup no nisam ga imao priliku probati u praksi. :(. Za dvojac koji posebno promoviraju CQRS(Udi Dahan i Greg Young, svaki sa svojeg stajališta), smatram da trenutno spadaju u vodeće mislioce s aspekta arhitekture složenih poslovnih sustava. 

Što se tiče pub/sub rješenja i messaging-a uopće ako slučajno niste pročitali, svakako preporučam Enterprise Integration Patterns by Hohpe, Woolf

Lp,

Hrvoje

Ovdje se u principu radi o komandama koje izlaze iz okvira SL-a, ali princip ostaje isti. U biti komande nisu ništa drugo nego obični DTO objekti čije ima sugerira namjeru. Npr. DeleteCustomerCommand gdje klasa sadrži samo one podatke koji su potrebni da se izvrši komanda.(recimo CustomerId). U principu, kod CQRS-a radi se o dizanju CQS principa na arhitekturalnu razinu. Po meni najveća snaga leži upravo u odvajanju i optimiziranju spremišta za pisanje i čitanje. Ako govorimo u konteksu relacijskih baza podataka, čitanje bi išlo iz denormaliziranih tabela, dok bi rezultati komanda spremali u normalizirani dio. 

Cijeli CQRS je koristan uglavnom kod izrade slozenijih SOA arhitektura, ali neki koncepti se mogu ukrasti u za malene aplikacije: odvojen read (query) model od command-a. Bez queue-a, async pozivanja i sync-a domain modela i read modela. To je vec dovoljno za pravilnu enkapsulaciju logike u aplikaciji i vecu kvalitetu koda. 

Hvala na prijedlogu za citanje ...

Nema problema :). 

Ne bi bilo loše otvoriti jedan topic i za razmjenu mišljenja/preporuke o knjigama :)

Pronašao sam MVVMLight :)

Kužim ja da je Prism debeli, teški, kompleksan i to, ali ako izostavimo veličinu, postoje li tu neki problemi za koje ja nisam svjestan ili je MVVMLight toliko bolji od Prism-a?

Može jedno konkretno pitanje šta se tiče SL-a, datagrid-a i MVVM?

Naime u datagrid row-u nije moguće doći do DataContext-a, pa me zanima jel ovo dobro rješenje za bindanje gumba u datagridu na command u VM-u?

1. Kreirao sam jednu turbo jednostavnu servis klasu:

 public class CurrentContextService : DependencyObject
    {
        public Object Context
        {
            get { return (Object)GetValue(ContextProperty); }
            set { SetValue(ContextProperty, value); }
        }
        public static readonly DependencyProperty ContextProperty =
            DependencyProperty.Register("Context", typeof(Object), typeof(CurrentContextService), new PropertyMetadata(null, new PropertyChangedCallback(ContextPromijenjen)));

        private static void ContextPromijenjen(DependencyObject o, DependencyPropertyChangedEventArgs e)
        {

        }
    }

2. u UserControl koja ima grid sam dodao resource i na Context DP servis klase bindao DataContext :

    <UserControl.Resources>
        <SharedServices:CurrentContextService x:Key="CurrentContextService"
                                              Context="{Binding ElementName=UserControlName, Path=DataContext}"></SharedServices:CurrentContextService>
    </UserControl.Resources>

kako ima def. konstruktor, xaml ga instancira bez problema...

3. U datagridu na gumb bindam komandu iz VM-a i proslijeđujem trenutnu vrijednost iz Item-a

                                   <Button Height="25"
                                            cal:Click.Command="{Binding Source={StaticResource CurrentContextService}, Path=Context.DodajCommand}"
                                            cal:Click.CommandParameter="{Binding}"">

4. Stvar štima

No, nekako mi se čini puno databindanja, bojim se kasnije eventualnog curenja memorije... Ima tko kakvu ideju jel ovo ok pristup?

Probaj to u DataGridu i poprilično sam siguran da ne radi :)

Znači datagrid, odnosno datagridcolumn ne vidi DataContext, te se i ne možeš na  njega bindati. Vidi jedino itemsource item i definirane resurse...

Pozdrav!

AFAIR, ovo sto je predlozio Hudo bi trebalo raditi. Takodjer, tvoje rjesenje je isto korektno IMO :)