Egy több képernyőből álló alkalmazás esetében nagyot profitálhatunk az MVVM-ből, ugyanis az MVVM Light Toolkit – és maga az MVVM szemlélet – az adatkötésekkel nagyban megkönnyíti a képernyők, vagy éppen lapok közötti adatmegosztást. A navigáció során, paramétereken keresztül történő kommunikáció helyett nézzünk néhány kifinomultabb eszközt a probléma megoldására!

Az alábbi bejegyzés elolvasása előtt javasolt az MVVM Light Toolkit-ről szóló sorozat első részének áttekintése, ahol az alapvető működés kerül bemutatásra.

ViewModelLocator – SimpleIoc

Az MVVM Light Toolkit önmagába foglal egy SimpleIoc nevezetű megoldást. A SimpleIoc egy Inversion of Control (IoC) konténer, melyet tipikusan a következőkre használhatunk:

• Osztályokat regisztrálhatunk a konténeren belül
• Alkalmazásunk bármely pontjáról lekérhetünk egy példányt a regisztrált osztályból
• A Singleton pattern-hez hasonlóan úgynevezett egyke példányokat kérhetünk le – a gyakorlatban ez annyit tesz, hogy egyetlen közös példányt használunk az alkalmazás életciklusa során, a példányban tárolt adatot az alkalmazás bármely részén elérjük
• Akár több példányt is tárolhatunk egyszerre, mindegyiket egy egyéni kulccsal eltárolva, így könnyen váltogathatunk közöttük

Az MVVM Light Toolkit a SimpleIoc-t tipikusan a ViewModel osztályok regisztrálására és példányosítására használja. Ezzel nem csak a ViewModel-ek közötti keresztlekérdezéseket tudjuk egyszerűbbé tenni, de a dizájn időben – Visual Studio-ban, vagy Blend-ben – történő adatmegjelenítést is rém egyszerűen megvalósíthatjuk, melyet a cikk végén letölthető példakódban be is mutatok.

Lássuk miként is lehet egy ViewModelLocator-t implementálni alkalmazásunkban – egyébként az implementációs lépéseket áttekintve rá fogunk jönni, hogy a ViewModelLocator nem más mint egy osztály, aminek az adattagjai lesznek a ViewModel osztályok egy-egy példányai, ezeket fogjuk átadni a felület DataContext paraméterének.

Implementáció

ViewModelLocator.cs:

[ecko_code_highlight language=”c#”]public class ViewModelLocator
{
static ViewModelLocator
{
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);

SimpleIoc.Default.Register<MainViewModel>();
}

public MainViewModel MainViewModel { get { return ServiceLocator.Current.GetInstance<MainViewModel>(); } }
}[/ecko_code_highlight]

ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
Első lépésként ezt érdemes megtennünk. Hogy miért? Egyszerűen nem a SimpleIoc az egyetlen provider amit használhatunk Írhatunk egy sajátot is akár, az IServiceLocator interfész implementálásával, valamint egy egyéni GetInstance függvény deklarálásával. Ha az alkalmazásunkban mindenhol a ServiceLocator.Current.GetInstance hívással kérdezünk le új példányt az objektumokból, akkor egy váltásnál megspóroljuk az összes hívás átírását, csak ezt az egy sort kell majd módosítanunk.

SimpleIoc.Default.Register<MainViewModel>();
Minden osztályt regisztrálnunk kell a SimpleIoc-n belül, mielőtt példányokat kérnénk le belőlük. Ezt kivétel nélkül minden esetben meg kell tennünk.

public MainViewModel MainViewModel { get { return ServiceLocator.Current.GetInstance<MainViewModel>(); } }
Végezetül pedig lekérünk egy új példányt a ViewModel-ből. Ha még nincs példány, akkor a SimpleIoc a háttérben automatán példányosítja az osztályt. A továbbiakban ugyanezt a példányt kapjuk meg mindig – kivéve ha másképp rendelkezünk, de erről még később írok.

App.xaml:

Az App.xaml fájlban meghatározhatunk úgynevezett erőforrásokat (Resource). Ezeknek több fajtája létezik, egyikük a kulcsokhoz társított osztálypéldányok – hasonlóképp, mint az IValueConverter osztályok esetében. Az App.xaml fájlban meghatározott erőforrásokat az alkalmazáson belül bárhonnan elérjük – legalábbis a projekten belül -, így a ViewModelLocator példányunkat itt hozzuk létre:

[ecko_code_highlight language=”html”]<Application x:Class=”MvvmCrossCommuncation.App”
xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation”
xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”
xmlns:local=”clr-namespace:MvvmCrossCommuncation”
xmlns:vm=”clr-namespace:MvvmCrossCommuncation.Core.ViewModels;assembly=MvvmCrossCommuncation.Core”
StartupUri=”MainWindow.xaml”>
<Application.Resources>
<ResourceDictionary>
<vm:ViewModelLocator x:Key=”ViewModelLocator” />
</ResourceDictionary>
</Application.Resources>
</Application>[/ecko_code_highlight]

xmlns:vm=”clr-namespace:MvvmCrossCommuncation.Core.ViewModels;assembly=MvvmCrossCommuncation.Core”
Először a xaml-ben megszokott módon meg kell adnunk egy új névteret, ahol ViewModelLocator osztályunkat létrehoztuk – általában én a ViewModel fájlok mellé szoktam helyezni.

<vm:ViewModelLocator x:Key=”ViewModelLocator” />
Ezt követően a megadott névtérből a ViewModelLocator egy új példányát létrehozzuk, majd megadunk neki egy tetszőleges kulcsot az x:Key paraméteren keresztül. A kulcsra a következő lépésben lesz szükségünk.

Az ilyen formában történő deklarációra gondolhatunk úgy, mintha a C# kódban a ViewModelLocator ViewModelLocator = new ViewModelLocator(); kódot írnánk be, tehát egy új példányt hozunk létre az osztályból.

DataContext

Mint azt már megtanultuk, az adatkötések működésre bírásához szükségünk van a DataContext megadására – ezzel adjuk meg, hogy a bekötötött adattagok pontosan hol is találhatók meg, milyen objektumon belül. Ezt azonban a korábbiaktól eltérően nem a C# kódban fogjuk megadni, hanem a felület XAML kódjában:

[ecko_code_highlight language=”html”]DataContext=”{Binding MainViewModel, Source={StaticResource ViewModelLocator}}”[/ecko_code_highlight]

Jól látjuk, hogy a DataContext itt szintén egy adatkötésből származik, de honnan is érkezik ez az adat? A MainViewModel maga az adattag neve, melyet a ViewModelLocator osztályunkban meghatároztunk, tehát ide minden esetben az adott ViewModel adattagjának a neve fog kerülni. Van azonban egy Source paraméterünk is, melyben a ViewModelLocator-t adtuk meg az adattag forrásának. Ezt azért tehetjük meg, mert az App.xaml fájlban felvettünk egy erőforrást ezzel a kulcs értékkel, ami a ViewModelLocator osztály egy példányát takarja.

A továbbiakban az adatkötések a korábban megszokott módon elvégezhetők, készen is vagyunk a ViewModelLocator bekötésével!

Jó ha tudod

Új példány lekérdezése, gyorsítótárazás nélkül

Lehetőség van minden alkalommal új példány lekérdezésére egy adott osztályból, ezt specifikusan a SimpleIoc tudja megvalósítani. A következő kóddal tehető meg a gyorsítótárazás nélküli példányosítás:

[ecko_code_highlight language=”c#”]return (ServiceLocator.Current as SimpleIoc).GetInstanceWithoutCaching<MainViewModel>();[/ecko_code_highlight]

Statikus adatok tervezési időben

A DataContext XAML-ben történő meghatározásának van egy nagy előnye: már dizájn időben is tudjuk, hogy honnan fogjuk megjeleníteni az adatokat. Ennek velejárója pedig, hogy a ViewModel-be kézzel felvett adatok mind-mind megjelennek a felületen már a Visual Studio, illetve Blend környezetben is. Az MVVM Light Toolkit ezt egy fokkal tovább is gondolta, a ViewModelBase.IsInDesignModeStatic változóval megtudhatjuk, hogy az előbbi két környezet egyikében vagyunk-e és feltölthetjük sablon adatokkal az alkalmazást.

[ecko_code_highlight language=”c#”]

static ViewModelLocator()
{
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);

SimpleIoc.Default.Register<CrossCommunicationViewModel>();
SimpleIoc.Default.Register<ScenariosViewModel>();
SimpleIoc.Default.Register<MessengerScenarioViewModel>();

if (ViewModelBase.IsInDesignModeStatic)
{
var ViewModel = new ViewModelLocator().MessengerScenarioViewModel;
ViewModel.Messages.Add(„See you in Blend or Visual Studio!”);
ViewModel.Messages.Add(„We have added this from code-behind.”);
ViewModel.Messages.Add(„This is a test message”);
}
}

[/ecko_code_highlight]

Tartsuk szem előtt, hogy a felületen csak akkor fognak megjelenni az adatok, ha újraforgatjuk a kódot!

ViewModel-ek között kommunikáció

Mivel a regisztrált osztályok példányai az alkalmazás teljes életciklusa alatt bárhonnan lekérdezhetővé váltak, így egyszerű dolgunk van, ha a ViewModel-ek között szeretnénk kommunikációt végrehajtani. Ezt megtehetjük C# és XAML kódból egyaránt. A következő példában egy adott ViewModel gyűjteményében az elemek számát kérdezzük le:

C#:
[ecko_code_highlight language=”c#”]public void Sample()
{
var messagesCount = new ViewModelLocator().MessengerScenarioViewModel.Messages.Count;
txtMessageCount.Text = messagesCount;
}[/ecko_code_highlight]

XAML:
[ecko_code_highlight language=”html”]<TextBlock x:Name=”txtMessageCount” Text=”{Binding MessengerScenarioViewModel.Messages.Count, Source={StaticResource ViewModelLocator}}” />[/ecko_code_highlight]

XAML DataContext elérése kódból

Ha szeretnénk a XAML-ben megadott DataContext-et a felület mögötti kódból elérni, használjuk a következő kódot:

[ecko_code_highlight language=”c#”]var ViewModel = (this.DataContext as TIPUS);[/ecko_code_highlight]

Ügyeljünk a megfelelő típuskonverzióra, valamint var helyett is használjuk az adott adattípust.

Messenger

Nem, most nem valamiféle csevegőszolgáltatásról fogunk beszélgetni! Az MVVM Light Toolkit csomagjában helyet kapott egy Messenger osztály, mellyel alkalmazásunk moduljai közötti kommunikációt fogunk megvalósítani.

A Messenger ereje abban rejlik, hogy úgynevezett csatornákra iratkozhatunk fel, melyeken meghatározott adattípusú üzeneteket várunk és ezeket felfolgozzuk valamilyen logikával. Ha az alkalmazás egy pontjáról üzenetet küldünk ezen a csatornán, a kezelő megkapja és a megadott logikával feldolgozza azt.

[ecko_code_highlight language=”c#”]Messenger.Default.Register<T>(
object recipient,
object token,
bool receiveDerivedMessagesToo,
Action<T> action
);[/ecko_code_highlight]

recipient: Az üzenet fogadója – egyszerűen this értéket írjuk be.
token (opcionális): A token paramétert felfoghatjuk egy úgynevezett kategóriaként, vagy a csatorna neveként. Ha a paramétert nem adjuk meg, akkor minden T típusú üzenetet fogadunk, ellenkező esetben csak az ugyanezzel a tokennel elküldött üzeneteket.
receiveDerivedMessagesToo (opcionális): A paraméter true értékre állításával a T típusból származtatott üzenettípusokat is fogadni fogjuk.
action: Azon függvény, mely fel fogja dolgozni a kapott üzenetet. Bemeneti paramétere egy T típusú objektum.

[ecko_code_highlight language=”c#”]Messenger.Default.Unregister<T>(
object recipient,
object token,
Action<T> action
);[/ecko_code_highlight]

A paraméterek jelentése ugyanaz, mint az előző esetben. A különbség, hogy ez a művelet megszünteti a regisztrált üzenetkezelőt.

[ecko_code_highlight language=”c#”]Messenger.Default.Send<T>(
T message,
object token
);[/ecko_code_highlight]

Elküldi T üzenetet – opcionálisan megadható token-nel. Az üzenet minden esetben elküldésre kerül, akár van fogadó fél, akár nincs.

[ecko_contrast]

A Messenger hátrányai

A Messenger kétségtelenül egy remek megoldásnak tűnik, azonban nem árt tisztában lenni ennek a megoldásnak a hátrányaival. Egy komplex alkalmazás esetében, ahol már rengeteg csatornán keresztül küldünk üzenetet, rendkívül nehézkessé válhat a hibák felderítése, ugyanis nem tudhatjuk, hogy egy adott üzenet az app mely pontjáról érkezett.

Hasonlóképpen egy üzenet elküldésekor nem kapunk visszajelzést arra vonatkozóan, hogy egy adott üzenettípusra van-e feliratkozott fogadó fél. Lehetséges, hogy a küldött üzenetek nem is érnek célba, mert nem regisztráltuk a fogadó felet, vagy valami hiba történt annak működése során és az a szál már régen elszállt.

Ez persze nem jelenti azt, hogy egyáltalán ne használjuk, de legyünk tisztában a megoldás korlátaival és eszerint határozzuk meg annak felhasználási köreit.[/ecko_contrast]

GitHub

A bejegyzéshez tartozó példakód elérhető a GitHub kódtáramban, érdemes megnézni a gyorsabb megértés érdekében!

Hiányolsz valamit a cikkből? Kérdésed van? Szólj hozzá a témához!