Jeg har engang startet et MVVM / WPF-projekt, som til sidst blev bygget og implementeret, og til det studerede jeg meget af Caliburn.Micro MVVM Framework. Faktum er: Jeg sluttede ikke med at bruge Caliburn.Micro til det og endte med at implementere nogle MVVM-koncepter selv (specifikt bare ViewModelBase og RoutedCommand klasser).
Nu fik jeg tildelt et noget større projekt i samme retning: en ” Single-User Rich Client Offline Desktop Application “, for at sige det, og jeg besluttede at bruge Caliburn.Micro. Og det “hvor mit ” problem ” begynder.
Jeg har læst i dette berømte blogindlæg , hvis titel siger, at ” Hvis du bruger MVVM, skal du har brug for en ramme “, at:
” At prøve at gøre noget som MVVM uden en ramme er en enorm mængde arbejde. Masser af duplikatkode, genopfinde hjulet og omskolere folk til at tænke anderledes .
I det mindste med en ramme, du undgår duplikatkoden og forhåbentlig ikke behøver at genopfinde hjulet – så du kan fokusere på omskoling af mennesker. Omskolingsdelen er generelt uundgåelig, men en ramme giver VVS-kode og struktur, hvilket gør processen lettere. ”
Jeg er enig i førstebehandlingen, men min faktiske erfaring med Caliburn.Micro (CM) i min faktiske ansøgning er cluelessness og desorientering. Det vil sige, at rammen overhovedet ikke gjorde processen nemmere, snarere det modsatte. At læse de gentagne eksempler fra Rob Eisenberg i den ret (for) uformelle dokumentation og forsøge at udlede brugsmønstre fra de indviklede prøver, og deres helt indirekte klasse- og interface-forhold, hvor ting ser ud til at være designet til at arbejde baseret på bivirkninger, synes menneskeligt umuligt, medmindre du er et erfaren geni (undskyld for rant, men jeg tror du ved hvad jeg mener).
For ikke at nævne, at ethvert ovenstående trivielt scenario synes at involvere IoC-containere, hvilket er noget, jeg aldrig har arbejdet med, og som ser ud til at løse et problem, som jeg måske ikke engang har . Jeg har ikke lyst til at bruge flere projekttimer på at lære disse ting i stedet for at tænke på mit problem og applikationsdomæner. Jeg ville bare have en banan, men CM gav mig en gorilla (IoC), der havde en kurv med bananer.
Nu hvor jeg overvejer at flytte tilbage til min hjemmespundne MVVM-ramme – kun sammensat af en håndfuld MVVM- specifikke klasser, som jeg faktisk vil implementere – jeg vil i det mindste gerne give CM en chance, hvis jeg mister noget her eller bare gør ting ” den forkerte måde ” af ren uerfarenhed og uvidenhed. Og så er spørgsmålet:
Der er bred enighed om, at ” rammer gør tingene lettere og mere naturlige “, men hvis jeg tilfældigvis oplever det modsatte, betyder det så, at jeg ikke skal bruge rammen, eller at jeg prøver at lære det på den forkerte måde? Er der en anelse om, at jeg ikke engang skulle bruge en ramme i første omgang? Eller er der en ” højre ” måde at finde ud af, hvordan man bruger CM til simpel MVVM-udvikling?
Kommentarer
Svar
Jeg har prøvet CaliburnMicro og MVVMLight og når jeg bruger Caliburn, føler jeg virkelig, hvad du føler, sikker på, at det føles virkelig magisk, i stand til at binde et kontrolelement til en ejendom bare ved at bruge Name = ” PropertyName ” i stedet for gammel Text = ” {Bind PropertyName} ” men til sidst går Caliburn langt overbord for at gøre denne magiske ting . Når noget går galt, er det virkelig svært at debugge og forværre tingene, de har mange måder at gøre en ting på.
I modsætning hertil er MVVMLight virkelig tynd. Når du bruger det, indser du sandsynligvis, at det næsten er 100% som dit MVVM Framework, med en eller anden funktion drysset i det.
Jeg ved, at det ikke svarer på dit spørgsmål ” Hvordan IKKE skal bruge framework ” men ærligt talt kan jeg ikke anbefale dig at gå den vej. Jeg tror, du er lige vild, fordi du brugte en komplet ramme i stedet for at bruge en simpel først.
Kommentarer
- Tror du, så at jeg i det mindste skulle prøve at bruge MVVMLight som en sort af ” cure ” fra ” Caliburn.Micro desorientering “? Jeg vil helt sikkert se på, hvis det er tilfældet.
- @heltonbiker Giv det bestemt. Det er så meget enklere, at det i det mindste skal give dig et godt fodfæste på MVVM Framework.
- Jeg er enig i, at der foregår alt for meget magi. Kommer jeg fra c og monteringsbaggrund antager jeg. E noget vandt ‘ kun for at finde det gør på grund af magi i baggrunden. Det er umuligt at debugge, og når du har problemer med ydeevnen, kan du ofte ikke gøre meget ved det.
Svar
Det er vigtigt at indse, hvad MVVM er. Det er ikke noget fælles bit af funktionalitet, som du ikke behøver at genimplementere (parsing af en JPEG-fil eller forbindelse til en given SQL-databaseserver), det er et mønster – et mønster for, hvordan man kan vælge at implementere en rig GUI. Så hvis din implementering af mønsteret er enkel og ligetil, tror jeg ikke, du har brug for at føle nogen skam ved at bruge det snarere end en ramme.
Faktisk tror jeg, at hele idéen om mønstre-som-rammer har gået alt for langt. For at noget skal være et mønster, skal det være den generelle form for en klasse af løsninger. Fordi dette er tilfældet, kan det forventes, at mønstre skal skræddersys til de systemer, der bruger dem, og du kan ikke gøre det, hvis du prøver at bruge et mønster, der passer til alle. Det ville være langt mere konstruktivt at overlade mønsterimplementering til applikationsdesigneren og levere biblioteker, der indkapsler funktionalitet snarere end arkitektur.
Kommentarer
- Føjet til at MVVM som Microsoft tilbyder (ud af boksen, WPF) mangler meget. Meget frustrerende selv for programmører, der tænker på sig selv (og med rette) som erfarne udviklere. Magiske strenge, uklare undtagelser i runtime, de mest basale ting som at binde en gruppe radioknapper til et enum ser ud som stackoverflow.com/q/397556/168719 – hvad kan rammer gøre? De skal enten ekko dette kompleksitetsniveau eller forsøge at give en virkelig tyk abstraktion over det
- @KonradMorawski WPF i sig selv er ikke MVVM; du kan lave kode bagud med WPF, men at ‘ ikke er MVVM. Så hvis du vil lave WPF og MVVM, skal du ‘ bruge en MVVM-ramme eller implementere en selv.
- @Andy selvfølgelig, men det ‘ er sikkert at sige, at WPF er beregnet til MMVM.Jeg ‘ henviser til MVVM-funktionalitet, der leveres indbygget med WPF. Jeg ved, at du stadig kan lave kode bag
- @KonradMorawski Du kan bruge WPF med MVVM, og de byggede den med denne mulighed i tankerne, men der er INGEN MVVM-specifik funktionalitet indbygget i WPF. Ligesom du kan bruge MVP med WinForms, men WinForms tilbyder ikke noget specifikt at bruge dette mønster, det er op til dig.
- @Andy måske ‘ skændes om definitioner nu. Hvad jeg mener er, at alt ” lim “, der gør MVVM mulig, er der allerede – databindinger i XAML,
DataContextosv.
Svar
Min første erfaring med WPF har været at bruge Caliburn. Micro, så dette er sandsynligvis ret forskelligt fra de fleste udviklere. Jeg har fundet både WPF og Caliburn.Micro er en ganske stejl indlæringskurve, der kommer fra WinForms, men efter nogle erfaringer med begge har jeg fundet dem en fornøjelse at bruge som et par. Arbejder i øjeblikket i en anden organisation, hvor Caliburn.Micro ikke bruges. Jeg finder ud af, at der er MEGET dobbelt duplikat VVS-kode, hvilket gør codebasen ret oppustet og unødvendigt kompleks.
Jeg er bestemt enig i, at der er nogle gotchas med Caliburn.Micro, som kan komplicere fejlretning, men når de først har oplevet, er de meget mindre tilbøjelige til at være smertefulde igen. Den øgede udviklingshastighed, renere og slankere kode og den overordnede ramme, der tilskynder til bedre MVVM, er mere end det værd for mig.
Caliburn.Micro annullerer heller ikke lager WPF – det bygger bare oven på det, hvilket betyder, at du stadig kan bruge WPF-funktioner, hvis du vil, og bruge Caliburn til et par stykker, hvis du vil. Dette svarer til, hvordan TypeScript og JavaScript eksisterer sammen i mit sind.
Jeg vil helt sikkert bruge Caliburn.Micro i ethvert nyt WPF-projekt, jeg arbejder på i fremtiden, hvis jeg får chancen.
Kommentarer
- Tak for dit svar. To år senere fandt jeg det meget lettere at ” acceptere ” disse rammer efter at have forstået begrebet Dependency Injection Containers, som jeg lærte af fremragende Mark Seeman ‘ s ” DI i .NET ” bog.
Svar
For alle, der ankommer her af frustration over Caliburn.Micro, se på denne ramme: Stylet
Det er inspireret af Caliburn.Micro, bortset fra at det fjerner meget af den magi, der efterlader dig desorienteret om, hvad der sker. Derudover er dokumentationen skrevet på meget klarere sprog uden at antage, at du vil vade gennem teknisk jargon. Meget bedre for begyndere.
Stylet tager også en ViewModel-First tilgang. Caliburn.Micro og mange andre rammer tager en View-First-tilgang, der kommer med nogle akavede problemer. Hvis du allerede er meget god til SOLID-principper og mønstret kode, vil du sandsynligvis finde en ViewModel-First-tilgang mere naturlig, da det tager perspektivet, at din logik skal drive systemet – ikke udsigten.
EventAggregatortil messaging ogNotificationObjecttil en ViewModelBase og MVVM Light ‘ sRelayCommandtil kommandoer. Det vigtige er at identificere, hvilke problemer rammen vil løse for dig, og kun bruge disse løsninger. Don ‘ føler ikke, at du ‘ er tvunget til at bruge hele rammebiblioteket.RelayCommandimplementering (da den ” binder ” direkte til metoder efter konvention i stedet for at binde til ICommand-egenskaber).RelayCommandfra et andet bibliotek, hvis det, der bruges af Caliburn Micro, ikke fungerer for dig.