MVVM-teljesítménytippek WinUI-alkalmazásokhoz

Ez a témakör az MVVM-hez, a kötésekhez és a megtekintési összetételhez kapcsolódó WinUI-alkalmazások teljesítményével kapcsolatos néhány szempontot tárgyal.

A Model-View-ViewModel (MVVM) tervezési minta

A Model-View-ViewModel (MVVM) minta sok WinUI-alkalmazásban gyakori. (Az MVVM nagyon hasonlít a Modell-View-Presenter minta Fowler leírásához, de XAML-hez igazodik). Az MVVM-mintával kapcsolatos probléma az, hogy véletlenül olyan alkalmazásokhoz vezethet, amelyek túl sok réteggel és túl sok foglalással rendelkeznek. Az MVVM motivációi ezek.

  • Az aggodalmak elkülönítése. Mindig hasznos, ha egy problémát kisebb részekre osztunk, és egy olyan minta, mint az MVVM vagy az MVC, egy alkalmazás (vagy akár egyetlen vezérlő) kisebb részekre osztható: a tényleges nézet, a nézet logikai modellje (nézetmodell) és a nézetfüggetlen alkalmazáslogika (a modell). Különösen népszerű munkafolyamat, ha a tervezők egy eszközzel birtokolják a nézetet, a fejlesztők a modellt egy másik eszközzel, a tervezői integrátorok pedig mindkét eszközzel birtokolják a nézetmodellt.
  • Egységtesztelés. A nézetmodellt (és következésképpen a modellt) a nézetétől függetlenül is tesztelheti, így nem támaszkodhat az ablakok létrehozására, a bemeneti adatok megadására és így tovább. Ha a nézetet kicsiben tartja, az alkalmazás nagy részét anélkül tesztelheti, hogy létre kellene hoznia egy ablakot.
  • A felhasználói élmény változásainak rugalmassága. A nézet általában a leggyakoribb módosításokat és a legkésettőbb módosításokat látja, mivel a felhasználói élmény a végfelhasználói visszajelzések alapján módosul. A nézet különválasztásával ezek a módosítások gyorsabban és kevesebb átalakítással hajthatók végre az alkalmazáson.

Az MVVM-minta több konkrét definíciója és a implementálását segítő külső keretrendszerek is léteznek. A minta bármely változatának szigorú betartása azonban sokkal nagyobb terhelést jelenthet az alkalmazásoknak, mint amennyi indokolt.

  • Az XAML-adatkötés ({Binding} korrektúrakiterjesztés) részben a modell-/nézetminták engedélyezésére lett tervezve. A {Binding} azonban nem triviális munkakészletet és processzorterhelést eredményez. A {Binding} létrehozása memóriafoglalások sorozatát okozza, és a kötési célpont frissítése reflectiont és boxolást okozhat. A WinUI-ban ezeket a problémákat az {x:Bind} korrektúrabvítménnyel oldjuk meg, amely a létrehozáskor fordítja le a kötéseket, és széles körben használják WinUI-mintákban és éles alkalmazásokban. Javaslat: {x:Bind} használata.
  • Az MVVM-ben népszerű a Button.Click eseményt egy nézetmodellhez csatlakoztatni egy ICommand használatával, például a gyakori DelegateCommand vagy RelayCommand segítő osztályokkal. Ezek a parancsok azonban további foglalások, beleértve a CanExecuteChanged eseményfigyelőt, hozzáadva a munkakészlethez, és hozzáadva a lap indítási/navigációs idejét. Ajánlás: A kényelmes ICommand felület használata helyett érdemes lehet az eseménykezelőket a kód mögé helyezni, csatolni őket a nézeteseményekhez, és meghívni egy parancsot a nézetmodellen az események felmerülésekor. További kódot is hozzá kell adnia a gomb letiltásához, ha a parancs nem érhető el.
  • Az MVVM-ben népszerű, ha a felhasználói felület összes lehetséges konfigurációjával rendelkező lapot hoz létre, majd összecsukja a fa egyes részeit, ha a Láthatóság tulajdonságot a virtuális gép tulajdonságaihoz köti. Ez szükségtelenül növeli az indítási időt és esetleg a munkakészletet (mivel előfordulhat, hogy a fa egyes részei soha nem válnak láthatóvá). Ajánlások: Az x:Load attribútum funkcióval elhalaszthatja a fa szükségtelen részeit az indításból. Emellett hozzon létre külön felhasználói vezérlőket a lap különböző módjaihoz, és használja a kód mögötti kódot, hogy csak a szükséges vezérlők legyenek betöltve.

Kapcsolódó tartalom

  • Last updated on