Egyszer elindítottam egy MVVM / WPF projektet, amelyet végül felépítettek és telepítettek, és ehhez sokat tanulmányoztam a Caliburn.Micro MVVM Framework-ben. A helyzet az, hogy végül nem használtam a Caliburn.Micro-t, és végül magam hajtottam végre néhány MVVM-koncepciót (konkrétan csak a ViewModelBase és a RoutedCommand osztályok).
Most egy kissé nagyobb projektet kaptam, ugyanazon a vonalon: a ” Egyfelhasználós Rich Client Offline asztali alkalmazás “, mondhatni, és úgy döntöttem, hogy a Caliburn.Micro fájlt használom. És itt kezdődik a ” problémám “.
Olvastam a ez a híres blogbejegyzés , amelynek címe szerint ” Ha MVVM-et használ, akkor kell egy keretrendszer “, amely:
” Az MVVM-hez hasonló keretrendszer nélküli próbálkozás hatalmas munka. Rengeteg duplikált kód, a kerék újrafeltalálása és az emberek átképzése másképp gondolkodni .
Legalábbis egy keretrendszer, amely elkerüli a duplikált kódot, és remélhetőleg nem kell újból feltalálnia a kereket – így az emberek átképzésére koncentrálhat. Az átképzési rész általában elkerülhetetlen, de a keretrendszer vízvezeték kódot és szerkezetet biztosít, megkönnyítve ezzel a folyamatot. ”
Egyetértek az első olvasattal, de tényleges tapasztalataimat a Caliburn.Micro (CM) a tényleges alkalmazásomban a tanácstalanság és a dezorientáció áll. Vagyis a keretrendszer egyáltalán nem tette könnyebbé a folyamatot, éppen ellenkezőleg. Olvassa el Rob Eisenberg folytonosan ismétlődő példáit a meglehetősen (is) informális dokumentációban, és próbáljon következtetni a használati mintákra az összevissza nyújtott mintákból, és teljesen közvetett osztály- és interfészviszonyaik, ahol úgy tűnik, hogy a dolgokat úgy tervezték, hogy a mellékhatásokon alapuljanak mire gondolok).
Arról nem is beszélve, hogy bármelyik fölöttébb triviális forgatókönyv úgy tűnik, hogy IoC-tárolókat tartalmaz, amivel soha nem dolgoztam, és amelyek úgy tűnik megold egy olyan problémát, amellyel esetleg nem is rendelkezem . Nincs kedvem több projektórát eltölteni a dolgok megtanulásával, ahelyett, hogy a problémámra és az alkalmazási területekre gondolnék. Csak egy banánt akartam, de a CM adott nekem egy gorillát (IoC), amelyben egy kosár banán volt.
Most, hogy fontolóra veszem, hogy visszaköltöznék az otthoni MVVM keretrendszerembe – amely csak maroknyi MVVM-ből áll – meghatározott osztályok, amelyeket ténylegesen meg akarok valósítani – szeretnék legalább esélyt adni a CM-nek, hátha itt elveszítek valamit, vagy egyszerűen csak rosszul csinálok dolgokat ” ” puszta tapasztalatlanságból és tudatlanságból. Ezért a kérdés a következő:
Széles körű egyetértés van abban, hogy a ” keretrendszerek megkönnyítik és természetesebbé teszik a dolgokat “, de ha véletlenül épp az ellenkezőjét tapasztalom, ez azt jelenti, hogy nem szabad használni a keretrendszert, vagy rosszul próbálom megtanulni? nyom, hogy eleve nem is kellene keretet használnom? Vagy van valami ” jobb ” módszer arra, hogy kitaláljuk, hogyan használjuk a CM-t az egyszerű MVVM-fejlesztéshez?
Megjegyzések
-t, mint a View-First fejlődés. A másik az automagikus összerendelés volt, amely az XAML-összetevők megnevezésére támaszkodott, mivel úgy gondoltam, hogy ez túlságosan lekötötte a felhasználói felületet az üzleti rétegre. Pedig jó dolgokat hallottam a keretrendszerről, és csak véleményem alapján nem javasolnám annak elkerülését. Próbáld ki magad, és nézd meg, tetszik-e 🙂
Válasz
Kipróbáltam a CaliburnMicro és az MVVMLight programokat és amikor a Caliburn-t használom, valóban érzem azt, amit érzel, és biztosan varázslatosnak tűnik, hogy a Name = ” PropertyName ” a régi Text = ” {Bind PropertyName} ” helyett, de végül Caliburn túlzásba esik, hogy ezt a varázslatos dolgot elvégezze . Ha valami elromlik, akkor nagyon nehéz hibakeresést végezni, és még rosszabbá tenni a helyzetet, nagyon sok módjuk van egy dolog elvégzésére.
Ezzel szemben az MVVMLight nagyon vékony. Amikor használja, akkor valószínűleg rájön, hogy majdnem 100% -osan hasonlít az MVVM Framework-hez, és van benne néhány funkció.
Tudom, hogy ez nem “válaszol a kérdésére ” Hogyan NEM használható a keretrendszer “, de őszintén szólva nem tudom javasolni, hogy haladjon ezen az úton. Azt hiszem, csak azért veszettél el, mert egy teljes funkcionalitású keretrendszert használtál, ahelyett, hogy először egy egyszerűt használtál volna.
Megjegyzések
- Akkor szerinted hogy legalább meg kell próbálnom használni az MVVMLight-ot a ” gyógyítás ” egyik sorosaként a ” Caliburn.Mikro dezorientáció “? Biztosan megnézném, ha ez a helyzet.
- @heltonbiker Határozottan, engedje meg. Sokkal egyszerűbb, ha legalább jó alapot ad az MVVM Framework-hez.
- Egyetértek azzal, hogy túl sok varázslat folyik. Feltételezem, hogy c és szerelési háttérből származik. E valami nem fog működni ‘ csak azért, hogy megtalálja a háttérben lévő varázslat miatt. Lehetetlen hibakeresés, és amikor teljesítményproblémái vannak, gyakran nem sokat tehet róla.
Válasz
Fontos felismerni, hogy mi az MVVM. Ez nem egy megosztott funkcionalitás, amelyet nem kell újratelepíteni (JPEG fájl elemzése vagy csatlakozás egy adott SQL adatbázis-kiszolgálóhoz), hanem egy minta – egy minta arra, hogy miként választhat gazdag GUI megvalósításához. Tehát, ha a minta megvalósítása egyszerű és egyértelmű, nem hiszem, hogy szégyent kellene éreznie a keretrendszer helyett.
Valójában úgy gondolom, hogy a minták mint keretek teljes ötlete túl messzire ment. Ahhoz, hogy bármi minta legyen, a megoldások osztályának általános alakjának kell lennie. Mivel ez így van, várható, hogy a mintákat az őket használó rendszerekhez kell igazítani, és ezt nem teheti meg, ha megpróbál egy mindenki számára megfelelő mintát használni. Sokkal konstruktívabb lenne, ha a minta megvalósítását az alkalmazás tervezőjére bíznák, és az architektúra helyett a funkcionalitást befogadó könyvtárakat biztosítanának.
Megjegyzések
- Hozzáadva hogy a Microsoft által kínált MVVM (dobozon kívül, WPF) nagyon hiányzik. Nagyon frusztráló azoknak a programozóknak is, akik tapasztalt fejlesztőként gondolják magukat (és helyesen). Varázslatos húrok, homályos kivételek a futás közben, a legalapvetőbb dolgok, például egy rádiógombok csoportjának az enumhoz való kötése úgy néz ki, mint stackoverflow.com/q/397556/168719 képesek-e a keretek? Vagy vissza kell adniuk ezt a bonyolultsági szintet, vagy meg kell próbálniuk egy igazán vastag absztrakciót biztosítani
- @KonradMorawski A WPF önmagában nem MVVM; kódot tehet a WPF segítségével, de ez ‘ nem MVVM. Tehát, ha WPF-et és MVVM-et szeretne csinálni, akkor ‘ használnia kell egy MVVM keretrendszert, vagy saját maga kell megvalósítania.
- Természetesen @Andy, de ‘ nyugodtan kijelenthetjük, hogy a WPF az MMVM számára készült.
m utalok a WPF-be beépített MVVM-funkcionalitásra. Tudom, hogy továbbra is megteheti a kódot
DataContext stb. Válasz
A WPF-el kapcsolatos első tapasztalatom a Caliburn használata volt. Micro, így ez valószínűleg meglehetősen eltér a legtöbb fejlesztőtől. Mind a WPF-et, mind a Caliburn.Micro-t meglehetősen meredek tanulási görbének találtam, amely a WinForms-ból származik, azonban mindkettővel szerzett tapasztalataim után azt tapasztaltam, hogy örömmel használom őket párként. Jelenleg egy másik szervezetben dolgozom, ahol a Caliburn.Micro nincs használatban. Megállapítom, hogy SOK duplikált vízvezeték-kód létezik, ami a kódbázist meglehetősen duzzadtá és szükségtelenül bonyolulttá teszi. a Caliburn.Micro-val, ami bonyolíthatja a hibakeresést, azonban miután egyszer megtapasztalták, sokkal kevésbé valószínű, hogy újra fájdalmat okoz. A megnövekedett fejlesztési sebesség, a tisztább és karcsúbb kód, valamint a jobb MVVM-t ösztönző általános keret több mint megéri nekem.
A Caliburn.Micro szintén nem érvényteleníti a részvény WPF-t – csak a tetejére épít, ami azt jelenti, hogy továbbra is használhatja a WPF funkcióit, ha úgy tetszik, és a Caliburn-t néhány darabra, ha úgy tetszik. Ez hasonlít arra, ahogyan a TypeScript és a JavaScript együtt élnek a fejemben.
A Caliburn.Micro-t minden bizonnyal minden új WPF-projektben használnám, amelyen a jövőben dolgozom, ha alkalom nyílik rá.
Megjegyzések
- Köszönjük válaszát. Két évvel később sokkal könnyebben ” elfogadtam ezeket a kereteket, miután megértettem a Függőségi Injekciós Konténerek fogalmát, amelyet a kiváló Mark Seeman ‘ s ” DI a .NET ” könyvben.
Válasz
Bárki, aki a Caliburn.Micro csalódottsága miatt érkezik ide, nézze meg ezt a keretrendszert: Stylet
A Caliburn.Micro ihlette, azzal a különbséggel, hogy eltávolítja azt a varázslatot, amely elzárkózik attól, ami történik. Ezenkívül a dokumentációt egyszerűbb nyelven írják, anélkül, hogy feltételeznénk, hogy át akarsz lépni a szakzsargonban. Sokkal jobb kezdőknek.
A Stylet szintén ViewModel-First megközelítést alkalmaz. Caliburn.Micro és sok más keretrendszer a View-First megközelítést alkalmazza, ami kínos problémákkal jár. Ha már nagyon ért a SOLID elvekhez és a mintás kódhoz, akkor valószínűleg természetesebbnek találja a ViewModel-First megközelítést, mivel abból a szempontból veszi figyelembe, hogy a logikának kell vezérelnie a rendszert – nem a nézetnek.
EventAggregatorüzenetküldéshez, ésNotificationObjecta ViewModelBase és az MVVM Light ‘ sRelayCommandparancsokhoz. A legfontosabb annak meghatározása, hogy a keretrendszer milyen problémákat fog megoldani az Ön számára, és csak ezeket a megoldásokat használja. Ne ‘ ne érezze úgy, hogy ‘ kénytelen lenne használni a teljes kerettárat.RelayCommandmegvalósítást (mivel ” a (z) ” szöveget közvetlenül egyezményekhez köti, ahelyett, hogy az ICommand tulajdonságaihoz kötődne).RelayCommandegy másik könyvtárból, ha a Caliburn Micro által használt könyvtár nem működik az Ön számára.