Jeg har en gang startet et MVVM / WPF-prosjekt, som til slutt ble bygget og distribuert, og for det studerte jeg mye av Caliburn.Micro MVVM Framework. Fakta er: Jeg endte opp ikke med å bruke Caliburn.Micro til det, og endte med å implementere noen MVVM-konsepter selv (spesifikt bare ViewModelBase og RoutedCommand klasser).
Nå ble jeg tildelt et noe større prosjekt i samme retning: en » Enbruker Rich Client Offline Desktop Application «, for å si det sånn, og jeg bestemte meg for å bruke Caliburn.Micro. Og det «der hvor mitt » problem » begynner.
Jeg har lest i dette berømte blogginnlegget , hvis tittel sier at » Hvis du bruker MVVM, så trenger et rammeverk «, at:
» Å prøve å gjøre noe som MVVM uten rammer er enormt mye arbeid. Tonnevis av duplikatkode, som gjenoppfinner hjulet, og omskoler folk til å tenke annerledes .
I det minste med et rammeverk du unngår duplikatkoden og forhåpentligvis ikke trenger å finne opp hjulet på nytt – slik at du kan fokusere på omskolering av mennesker. Omskolingsdelen er generelt uunngåelig, men et rammeverk gir VVS-kode og struktur, noe som gjør prosessen enklere. »
Jeg er enig i første lesning, men min faktiske erfaring med Caliburn.Micro (CM) i min faktiske applikasjon er det å være cluelessness og desorientering. Det vil si at rammeverket ikke gjorde prosessen lettere i det hele tatt, snarere motsatt. Å lese de stadig gjentatte eksemplene som ble gitt av Rob Eisenberg i den ganske (for) uformelle dokumentasjonen, og prøve å utlede bruksmønstre fra de innviklede prøvene, og deres helt indirekte klasse- og grensesnittforhold, der ting ser ut til å være designet for å fungere basert på bivirkninger, virker menneskelig umulig med mindre du er et erfaren geni (beklager rant, men jeg antar at du vet hva jeg mener).
For ikke å nevne at noe over trivielt scenario ser ut til å involvere IoC-containere, noe som jeg aldri har jobbet med, og som ser ut til å løse et problem jeg kanskje ikke engang har . Jeg har ikke lyst til å bruke flere prosjektimer på å lære disse tingene i stedet for å tenke på problemene mine og applikasjonsdomenene. Jeg ville bare ha en banan, men CM ga meg en gorilla (IoC) som hadde en kurv med bananer.
Nå som jeg vurderer å flytte tilbake til min hjemmespunne MVVM-ramme – bare sammensatt av en håndfull MVVM- spesifikke klasser jeg faktisk vil implementere – jeg vil i det minste gi CM en sjanse, hvis jeg mister noe her, eller bare gjør ting » feil måte » av ren uerfarenhet og uvitenhet. Og så er spørsmålet:
Det er bred enighet om at » rammer gjør ting enklere og mer naturlige «, men hvis jeg tilfeldigvis opplever det motsatte, betyr dette at jeg ikke burde bruke rammeverket, eller at jeg prøver å lære det på feil måte? anelse om at jeg ikke engang skulle bruke et rammeverk i utgangspunktet? Eller er det noen » høyre » måte å finne ut hvordan du bruker CM til enkel MVVM-utvikling?
Kommentarer
Svar
Jeg har prøvd CaliburnMicro og MVVMLight og når jeg bruker Caliburn, føler jeg virkelig hva du føler, at det føles veldig magisk, i stand til å binde en kontroll til en eiendom bare ved å bruke Name = » PropertyName » i stedet for gammel Text = » {Bind PropertyName} » men til slutt går Caliburn langt over bord for å gjøre denne magiske tingen . Når noe går galt, er det veldig vanskelig å feilsøke, og for å gjøre ting verre, har de mange måter å gjøre en ting på.
Derimot er MVVMLight veldig tynn. Når du bruker den, skjønner du sannsynligvis at den er nesten 100% som MVVM Framework, med noen funksjoner i.
Jeg vet at dette ikke svarer på spørsmålet ditt » Hvordan IKKE bruke rammeverk » men ærlig talt kan jeg ikke anbefale deg å gå den ruten. Jeg tror du bare er tapt fordi du brukte et fullverdig rammeverk i stedet for å bruke et enkelt først.
Kommentarer
- Tror du da, at jeg i det minste skulle prøve å bruke MVVMLight som en eller annen sort av » cure » fra » Caliburn.Micro desorientering «? Jeg vil helt sikkert ta en titt hvis det er tilfelle.
- @heltonbiker Definitivt, gi det en sjanse. Det er så mye enklere, i det minste skal du gi deg et godt fotfeste på MVVM Framework.
- Jeg er enig i at det er altfor mye magi på gang. Kommer fra c og monteringsbakgrunn antar jeg. E noe vant ‘ ikke bare for å finne det gjør på grunn av magi i bakgrunnen. Umulig å feilsøke, og når du har ytelsesproblemer, kan du ofte ikke gjøre noe med det.
Svar
Det er viktig å innse hva MVVM er. Det er ikke noe delt bit av funksjonalitet du ikke trenger å implementere på nytt (parsing av en JPEG-fil eller kobling til en gitt SQL-databaseserver), det er et mønster – et mønster for hvordan man kan velge å implementere en rik GUI. Så hvis implementeringen din av mønsteret er enkel og grei, tror jeg ikke du trenger å føle noen skam i å bruke det i stedet for et rammeverk.
Jeg tror faktisk hele mønster-som-rammeverk-ideen har gått altfor langt. For at alt skal være et mønster, må det være den generelle formen på en klasse med løsninger. Fordi dette er slik, er det å forvente at mønstre må skreddersys til systemene som bruker dem, og du kan ikke gjøre det hvis du prøver å bruke et mønster som passer alle. Det ville være langt mer konstruktivt å overlate mønsterimplementering til applikasjonsdesigneren og tilby biblioteker som innkapsler funksjonalitet, i stedet for arkitektur.
Kommentarer
- Lagt til at MVVM som tilbys av Microsoft (out of the box, WPF) mangler veldig mye. Veldig frustrerende selv for programmerere som tenker på seg selv (og med rette) som erfarne utviklere. Magiske strenger, uklare unntak i kjøretid, mest grunnleggende ting som å binde en gruppe radioknapper til en enum ser ut som stackoverflow.com/q/397556/168719 – hva kan rammer gjøre? De må enten ekko dette nivået av kompleksitet, eller prøve å gi en veldig tykk abstraksjon over den
- @KonradMorawski WPF i seg selv er ikke MVVM; du kan gjøre kode bak med WPF, men at ‘ ikke er MVVM. Så hvis du vil gjøre WPF og MVVM, må du ‘ bruke et MVVM-rammeverk eller implementere en selv.
- @Andy selvfølgelig, men det ‘ er trygt å si at WPF er ment for MMVM.Jeg ‘ refererer til MVVM-funksjonalitet som er innebygd med WPF. Jeg vet at du fremdeles kan gjøre kode bak
- @KonradMorawski Du kan bruke WPF med MVVM, og de bygget den med den muligheten i tankene, men det er INGEN MVVM-spesifikk funksjonalitet innebygd i WPF. Akkurat som du kan bruke MVP med WinForms, men WinForms tilbyr ikke noe spesielt å bruke det mønsteret, det er opp til deg.
- @Andy kanskje vi ‘ diskuterer om definisjoner nå. Det jeg mener er at alt » limet » som gjør MVVM mulig, er allerede der – databindinger i XAML,
DataContextetc.
Svar
Min første erfaring med WPF har vært å bruke Caliburn. Micro så dette er sannsynligvis ganske forskjellig fra de fleste utviklere. Jeg har funnet både WPF og Caliburn.Micro er ganske bratt læringskurve, kommer fra WinForms, men etter litt erfaring med begge har jeg funnet dem en glede å bruke som et par. Jobber for tiden i en annen organisasjon der Caliburn.Micro ikke brukes. Jeg finner ut at det er MYE duplikat VVS-kode som gjør kodebasen ganske oppblåst og unødvendig komplisert.
Jeg er absolutt enig i at det er noen gotchas med Caliburn.Micro, som kan komplisere feilsøking, men når de først har opplevd, er det mye mindre sannsynlig at de blir vondt igjen. Den økte utviklingshastigheten, renere og slankere koden og det overordnede rammeverket som oppmuntrer til bedre MVVM er mer enn verdt det for meg.
Caliburn.Micro ugyldiggjør heller ikke lager WPF – det bygger bare på toppen av det, noe som betyr at du fortsatt kan bruke WPF-funksjoner hvis du vil, og bruke Caliburn for noen få stykker hvis du vil. Dette ligner på hvordan TypeScript og JavaScript eksisterer sammen i mitt sinn.
Jeg vil absolutt bruke Caliburn.Micro i ethvert nytt WPF-prosjekt jeg jobber med i fremtiden hvis jeg får sjansen.
Kommentarer
- Takk for svaret. To år senere fant jeg mye lettere å » godta » disse rammene etter å ha forstått konseptet Dependency Injection Containers, som jeg lærte av utmerket Mark Seeman ‘ s » DI i .NET » bok.
Svar
For alle som kommer hit av frustrasjon over Caliburn.Micro, ta en titt på dette rammeverket: Stylet
Den er inspirert av Caliburn.Micro, bortsett fra at den fjerner mye av magien som etterlater deg desorientert om hva som skjer. I tillegg er dokumentasjonen skrevet på mye klarere språk uten å anta at du vil vasse gjennom teknisk sjargong. Mye bedre for nybegynnere.
Stylet tar også en ViewModel-First-tilnærming. Caliburn.Micro og mange andre rammer tar en View-First-tilnærming, som kommer med noen vanskelige problemer. Hvis du allerede er veldig god på SOLID-prinsipper og mønstret kode, vil du sannsynligvis finne en ViewModel-First-tilnærming mer naturlig, siden det tar perspektivet at logikken din skal drive systemet – ikke visningen.
EventAggregatorfor meldinger, ogNotificationObjectfor en ViewModelBase og MVVM Light ‘ sRelayCommandfor kommandoer. Det viktige er å identifisere hvilke problemer rammeverket skal løse for deg, og bare bruke disse løsningene. Ikke ‘ t føler at du ‘ tvunget til å bruke hele rammebiblioteket.RelayCommandimplementering (siden den » binder » direkte til metoder etter konvensjon, i stedet for å binde til ICommand-egenskaper).RelayCommandfra et annet bibliotek hvis det som brukes av Caliburn Micro ikke fungerer for deg.