Ik ben ooit een MVVM / WPF-project gestart, dat uiteindelijk werd gebouwd en geïmplementeerd, en daarvoor heb ik veel van het Caliburn.Micro MVVM Framework bestudeerd. Het feit is: ik heb daarvoor niet Caliburn.Micro gebruikt, en heb uiteindelijk zelf een aantal MVVM-concepten geïmplementeerd (met name alleen de ViewModelBase en RoutedCommand klassen).
Nu werd ik toegewezen aan een wat groter project volgens dezelfde lijnen: een ” Single-User Rich Client Offline Desktop-applicatie “, om zo te zeggen, en ik besloot Caliburn.Micro te gebruiken. En dat is waar mijn ” probleem ” begint.
Ik heb gelezen in deze beroemde blogpost , waarvan de titel zegt dat ” Als je” MVVM gebruikt, dan hebben een framework ” nodig, dat:
” Het is enorm veel werk om zoiets als MVVM te doen zonder framework. Tonnen dubbele code, het wiel opnieuw uitvinden, en mensen omscholen om anders te denken .
Tenminste met een raamwerk waarmee u de dubbele code vermijdt en hopelijk het wiel niet opnieuw hoeft uit te vinden – waardoor u zich kunt concentreren op het omscholen van mensen. Het omscholingsgedeelte is over het algemeen onvermijdelijk, maar een raamwerk biedt sanitaire code en structuur, waardoor het proces eenvoudiger wordt. ”
Ik ben het eens bij de eerste lezing, maar mijn werkelijke ervaring met Caliburn.Micro (CM) in mijn daadwerkelijke applicatie is van cluelessness en desoriëntatie. Dat wil zeggen, het raamwerk maakte het proces helemaal niet eenvoudiger, integendeel. Het lezen van de steeds herhalende voorbeelden van Rob Eisenberg in de nogal (te) informele documentatie, en proberen gebruikspatronen af te leiden uit de ingewikkelde aangeleverde voorbeelden, en hun volkomen indirecte klasse- en interfacerelaties, waarbij dingen ontworpen lijken om gebaseerd te werken op bijwerkingen, lijken menselijkerwijs onmogelijk tenzij je een doorgewinterd genie bent (sorry voor de tirade, maar ik denk dat je weet wat ik bedoel).
Om nog maar te zwijgen van het feit dat elk boven-triviaal scenario IoC-containers lijkt te omvatten, iets waar ik nog nooit mee heb gewerkt en die los een probleem op dat ik misschien niet eens heb . Ik heb geen zin om meer projecturen te besteden aan het leren van die dingen in plaats van na te denken over mijn probleem en toepassingsdomeinen. Ik wilde gewoon een banaan, maar CM gaf me een gorilla (IoC) met een mand met bananen.
Nu ik overweeg om terug te gaan naar mijn zelfgemaakte MVVM-raamwerk – alleen samengesteld uit een handvol MVVM- specifieke klassen die ik eigenlijk wil implementeren – ik zou CM op zijn minst een kans willen geven, voor het geval ik hier iets verlies, of gewoon dingen ” op de verkeerde manier doe ” uit pure onervarenheid en onwetendheid. En dus is de vraag:
Er is een brede consensus dat ” frameworks dingen gemakkelijker en natuurlijker maken “, maar als ik toevallig het tegenovergestelde ervaar, betekent dit dan dat ik het framework niet moet gebruiken of dat ik het op de verkeerde manier probeer te leren? Is er een aanwijzing dat ik in de eerste plaats niet eens een framework zou moeten gebruiken? Of is er een ” juiste ” manier om erachter te komen hoe je CM kunt gebruiken voor eenvoudige MVVM-ontwikkeling?
Reacties
Answer
Ik heb CaliburnMicro en MVVMLight geprobeerd en als ik Caliburn gebruik, voel ik echt wat je voelt, ik weet zeker dat het echt magisch aanvoelt in staat om een besturingselement aan een eigenschap te binden door gewoon Name = ” PropertyName ” in plaats van de oude Text = ” {Bind PropertyName} ” maar uiteindelijk gaat Caliburn ver overboord om dit magische ding te doen . Als er iets misgaat, is het erg moeilijk om fouten op te sporen en om het nog erger te maken, ze hebben veel manieren om één ding te doen.
Daarentegen is MVVMLight erg dun. Als je het gebruikt, realiseer je je waarschijnlijk dat het bijna 100% lijkt op je MVVM Framework, met een of andere functie erin.
Ik weet dat dit je vraag niet “beantwoordt ” Hoe je framework NIET gebruikt ” maar eerlijk gezegd kan ik je niet aanraden om die route te gaan. Ik denk dat je gewoon verdwaald bent omdat je een volledig uitgerust raamwerk hebt gebruikt in plaats van eerst een eenvoudig te gebruiken.
Opmerkingen
- Denk je dan, dat ik op zijn minst zou moeten proberen om MVVMLight te gebruiken als een soort ” genezing ” van ” Caliburn.Micro desoriëntatie “? Ik zou zeker een kijkje nemen als dat het geval is.
- @heltonbiker Zeker, probeer het eens. Het is zo veel eenvoudiger en zou je in ieder geval een goede basis moeten geven op MVVM Framework.
- Ik ben het ermee eens dat er veel te veel magie aan de hand is. Afkomstig van een c en montage achtergrond neem ik aan. Iets werkt niet ‘ alleen om te ontdekken dat het werkt vanwege magie op de achtergrond. Onmogelijk om fouten op te sporen en als u prestatieproblemen heeft, kunt u er vaak niet veel aan doen.
Antwoord
Het is belangrijk om te beseffen wat MVVM is. Het is niet een gedeeld stukje functionaliteit dat u niet opnieuw hoeft te implementeren (een JPEG-bestand ontleden of verbinding maken met een bepaalde SQL-databaseserver), het is een patroon – een patroon voor hoe men kan kiezen om een rijke GUI te implementeren. Dus als je implementatie van het patroon eenvoudig en duidelijk is, denk ik niet dat je je hoeft te schamen om het te gebruiken in plaats van een raamwerk.
Inderdaad, ik geloof dat het hele patroon-als-raamwerk-idee heeft veel te ver gegaan. Om een patroon te kunnen zijn, moet het de algemene vorm zijn van een klasse van oplossingen. Omdat dit zo is, is het te verwachten dat patronen moeten worden aangepast aan de systemen die ze gebruiken en dat kun je niet doen als je een one-size-fits-all-patroon probeert te gebruiken. Het zou veel constructiever zijn om de patroonimplementatie aan de applicatieontwerper over te laten en bibliotheken te bieden die functionaliteit inkapselen, in plaats van architectuur.
Opmerkingen
- Toegevoegd aan dat MVVM zoals aangeboden door Microsoft (out of the box, WPF) erg ontbreekt. Zeer frustrerend, zelfs voor programmeurs die zichzelf (en terecht) beschouwen als doorgewinterde ontwikkelaars. Magische strings, obscure uitzonderingen in runtime, de meeste basale dingen zoals het binden van een groep radioknoppen aan een enum ziet eruit als stackoverflow.com/q/397556/168719 – wat kunnen frameworks doen? Ze moeten ofwel dit niveau van complexiteit weerspiegelen, ofwel proberen er een heel dikke abstractie overheen te geven.
- @KonradMorawski WPF is op zichzelf geen MVVM; je kunt code achter doen met WPF, maar dat ‘ is geen MVVM. Dus als je WPF en MVVM wilt doen, moet je ‘ een MVVM-framework gebruiken of er zelf een implementeren.
- @Andy natuurlijk, maar het ‘ Het is veilig om te zeggen dat WPF bedoeld is voor MMVM.Ik ‘ m verwijzend naar de MVVM-functionaliteit die is ingebouwd in WPF. Ik weet dat je nog steeds code achter kunt doen.
- @KonradMorawski Je kunt WPF gebruiken met MVVM, en ze hebben het gebouwd met die mogelijkheid in gedachten, maar er is GEEN MVVM-specifieke functionaliteit ingebouwd in WPF. Net zoals je MVP kunt gebruiken met WinForms, maar WinForms biedt niets specifieks om dat patroon te gebruiken, het is aan jou.
- @Andy misschien ‘ hebben ruzie over definities nu. Wat ik bedoel is dat alle ” lijm ” die MVVM mogelijk maakt er al is – gegevensbindingen in XAML,
DataContextetc.
Answer
Mijn eerste ervaring met WPF is het gebruik van Caliburn. Micro dus dit is waarschijnlijk heel anders dan de meeste ontwikkelaars. Ik heb zowel WPF als Caliburn.Micro als een behoorlijk steile leercurve ervaren, afkomstig van WinForms, maar na enige ervaring met beide vond ik het een plezier om ze als een paar te gebruiken. Momenteel werk ik in een andere organisatie waar Caliburn.Micro niet wordt gebruikt.Ik merk dat er VEEL dubbele loodgieterscode is, wat de codebase behoorlijk opgeblazen en onnodig complex maakt.
Ik ben het er absoluut mee eens dat er een paar valstrikken zijn met Caliburn.Micro, wat foutopsporing kan bemoeilijken, maar als ze eenmaal zijn ervaren, is de kans veel kleiner dat ze weer vervelend zijn. De verhoogde ontwikkelingssnelheid, schonere en slankere code en het algehele framework dat betere MVVM aanmoedigt, zijn het voor mij meer dan waard.
Caliburn.Micro maakt ook de voorraad WPF niet ongeldig – het bouwt er gewoon bovenop, wat betekent dat je nog steeds WPF-functies kunt gebruiken als je wilt en Caliburn voor een paar stukjes en beetjes kunt gebruiken als je wilt. Dit is vergelijkbaar met hoe TypeScript en JavaScript in mijn hoofd naast elkaar bestaan.
Ik zou Caliburn.Micro zeker gebruiken in elk nieuw WPF-project waaraan ik in de toekomst werk als ik de kans krijg.
Reacties
- Bedankt voor je antwoord. Twee jaar later vond ik het veel gemakkelijker om ” ” deze frameworks te accepteren nadat ik het concept van Dependency Injection Containers had begrepen, dat ik leerde van de uitstekende Mark Seeman ‘ s ” DI in .NET ” boek.
Antwoord
Voor iedereen die hier arriveert uit frustratie over Caliburn.Micro, kijk eens naar dit raamwerk: Stylet
Het is geïnspireerd door Caliburn.Micro, behalve dat het veel van de magie verwijdert waardoor je gedesoriënteerd raakt over wat er gebeurt. Bovendien is de documentatie in veel duidelijkere taal geschreven zonder aan te nemen dat je door technisch jargon wilt waden. Veel beter voor beginners.
Ook hanteert Stylet een ViewModel-First-benadering. Caliburn.Micro en veel andere frameworks gebruiken een View-First-benadering, die gepaard gaat met enkele lastige problemen. Als je al heel goed bent in SOLID-principes en patrooncode, zul je waarschijnlijk een ViewModel-First-benadering natuurlijker vinden, omdat deze vanuit het perspectief gaat dat je logica het systeem moet aansturen – niet de weergave.
EventAggregatorvoor berichten, enNotificationObjectvoor een ViewModelBase en MVVM Light ‘ sRelayCommandvoor opdrachten. Het belangrijkste is om vast te stellen welke problemen het raamwerk voor u gaat oplossen en alleen die oplossingen te gebruiken. ‘ voel je niet alsof je ‘ gedwongen bent om de volledige framework-bibliotheek te gebruiken.RelayCommand-implementatie vinden (aangezien deze ” bindt ” rechtstreeks aan methoden volgens afspraak, in plaats van te binden aan ICommand-eigenschappen).RelayCommanduit een andere bibliotheek als degene die wordt gebruikt door Caliburn Micro niet voor u werkt.