Jag har en gång startat ett MVVM / WPF-projekt, som så småningom byggdes och distribuerades, och för det studerade jag mycket av Caliburn.Micro MVVM Framework. Faktum är: Jag slutade inte med Caliburn.Micro för det och slutade med att implementera några MVVM-koncept själv (specifikt bara ViewModelBase och RoutedCommand klasser).
Nu tilldelades jag ett något större projekt i samma riktning: en ” Enkelanvändare Rich Client Offline Desktop Application ”, så att säga, och jag bestämde mig för att använda Caliburn.Micro. Och det är där mitt ” problem ” börjar.
Jag har läst i detta berömda blogginlägg , vars titel säger att ” Om du använder MVVM så behöver ett ramverk ”, att:
” Att försöka göra något som MVVM utan ram är enormt mycket arbete. Massor av dubblettkod, återuppfinna hjulet och omskolning av människor att tänka annorlunda .
Åtminstone med ett ramverk som du undviker dupliceringskoden och förhoppningsvis inte behöver uppfinna hjulet på nytt – så att du kan fokusera på omskolning. Omskolningsdelen är i allmänhet oundviklig, men ett ramverk ger VVS-kod och struktur, vilket gör processen enklare. ”
Jag håller med om första behandlingen men min faktiska erfarenhet av Caliburn.Micro (CM) i min faktiska applikation är det att vara orolig och desorienterad. Det vill säga att ramverket inte alls gjorde processen enklare, tvärtom. Att läsa de ständigt upprepande exemplen från Rob Eisenberg i den ganska (alltför) informella dokumentationen och försöka dra slutsatser om användningsmönster från de invecklade proverna, och deras helt indirekta klass- och gränssnittsförhållanden, där saker verkar vara utformade för att fungera baserat på biverkningar, verkar mänskligt omöjligt om du inte är en erfaren geni (ledsen för rant, men jag antar att du vet vad jag menar).
För att inte tala om att något ovan-trivialt scenario verkar involvera IoC-behållare, vilket är något jag aldrig har arbetat med, och som verkar lösa ett problem som jag kanske inte ens har . Jag känner inte att jag spenderar mer projekttimmar på att lära mig dessa saker istället för att tänka på mina problem och applikationsdomäner. Jag ville bara ha en banan, men CM gav mig en gorilla (IoC) med en korg med bananer.
Nu när jag överväger att flytta tillbaka till mitt hemspunna MVVM-ramverk – består bara av en handfull MVVM- specifika klasser som jag faktiskt vill implementera – jag skulle åtminstone vilja ge CM en chans, om jag tappar något här eller helt enkelt gör saker ” på fel sätt ” av ren bristande erfarenhet och okunnighet. Och så är frågan:
Det finns bred enighet om att ” ramar gör saker enklare och mer naturliga ”, men om jag råkar uppleva tvärtom betyder det att jag inte borde använda ramverket eller att jag försöker lära mig det på fel sätt? Finns det en aning om att jag inte ens skulle använda ett ramverk i första hand? Eller finns det något ” rätt ” sätt att ta reda på hur man använder CM för enkel MVVM-utveckling?
Kommentarer
Svar
Jag har provat CaliburnMicro och MVVMLight och när jag använder Caliburn känner jag verkligen vad du känner, säker på att det känns riktigt magiskt att kunna binda en kontroll till en egendom bara genom att använda Name = ” PropertyName ” istället för gammal Text = ” {Bind PropertyName} ” men i slutändan går Caliburn långt överbord för att göra den här magiska saken . När något går fel är det väldigt svårt att felsöka och förvärra saker och ting. De har många sätt att göra en sak.
Däremot är MVVMLight väldigt tunn. När du använder den inser du förmodligen att den är nästan 100% som din MVVM Framework, med någon funktion strödd i den.
Jag vet att det inte svarar på din fråga ” Hur man INTE använder ramverk ” men uppriktigt sagt kan jag inte rekommendera att du går den vägen. Jag tror att du bara är förlorad eftersom du använde ett fullständigt ramverk istället för att använda ett enkelt först.
Kommentarer
- Tror du då, att jag åtminstone skulle försöka använda MVVMLight som någon sort av ” cure ” från ” Caliburn.Micro desorientering ”? Jag skulle säkert ta en titt om så är fallet.
- @heltonbiker Definitivt, ge det en chans. Det är så mycket enklare borde åtminstone ge dig ett bra fotfäste på MVVM Framework.
- Jag håller med om att det finns alldeles för mycket magi på gång. Kommer från c- och monteringsbakgrund antar jag. E något vinner ’ inte bara för att hitta det på grund av magi i bakgrunden. Omöjligt att felsöka och när du har prestationsproblem kan du ofta inte göra så mycket.
Svar
Det är viktigt att inse vad MVVM är. Det är inte någon delad bit av funktionalitet som du inte behöver implementera om (analysera en JPEG-fil eller ansluta till en viss SQL-databasserver), det är ett mönster – ett mönster för hur man kan välja för att implementera ett rikt GUI. Så om din implementering av mönstret är enkel och rak, tror jag inte att du behöver känna någon skam för att använda det snarare än en ram.
Jag tror faktiskt att hela mönster-som-ram-idén har gått mycket för långt. För att allt ska vara ett mönster måste det vara den allmänna formen av en klass av lösningar. Eftersom detta är så är det att förvänta sig att mönster kommer att behöva skräddarsys för de system som använder dem och du kan inte göra det om du försöker använda ett mönster som passar alla. Det vore mycket mer konstruktivt att lämna mönsterimplementering till applikationsdesignern och tillhandahålla bibliotek som inkapslar funktionalitet snarare än arkitektur.
Kommentarer
- Tillagt det, MVVM som erbjuds av Microsoft (out of the box, WPF) saknas väldigt mycket. Mycket frustrerande även för programmerare som tänker på sig själva (och med rätta) som erfarna utvecklare. Magiska strängar, dunkla undantag under körning, mest grundläggande saker som att binda en grupp radioknappar till ett enum ser ut som stackoverflow.com/q/397556/168719 – vad kan ramar göra? De måste antingen upprepa denna nivå av komplexitet eller försöka ge en riktigt tjock abstraktion över den
- @KonradMorawski WPF i sig är inte MVVM; du kan göra koden bakom med WPF, men att ’ inte är MVVM. Så om du vill göra WPF och MVVM måste du ’ använda ett MVVM-ramverk eller implementera en själv.
- @Andy förstås, men det ’ är säkert att säga att WPF är avsedd för MMVM.Jag ’ jag hänvisar till MVVM-funktionalitet som levereras inbyggd med WPF. Jag vet att du fortfarande kan göra kod bakom
- @KonradMorawski Du kan använda WPF med MVVM, och de byggde den med den möjligheten i åtanke, men det finns INGEN MVVM-specifik funktionalitet inbyggd i WPF. Precis som du kan använda MVP med WinForms, men WinForms erbjuder inget specifikt att använda det mönstret, det är upp till dig.
- @Andy kanske vi ’ diskuterar om definitioner nu. Vad jag menar är att allt ” lim ” som gör MVVM möjligt finns redan – databindningar i XAML,
DataContextetc.
Svar
Min första erfarenhet av WPF har varit att använda Caliburn. Micro så det här är nog helt annorlunda än de flesta utvecklare. Jag har hittat både WPF och Caliburn.Micro är en ganska brant inlärningskurva, kommer från WinForms, men efter lite erfarenhet av båda har jag funnit dem ett nöje att använda som par. Arbetar för närvarande i en annan organisation där Caliburn.Micro inte används. Jag tycker att det finns MYCKET duplicerad VVS-kod som gör kodbasen ganska uppsvälld och onödigt komplex.
Jag håller definitivt med om att det finns några gotchas med Caliburn.Micro, vilket kan komplicera felsökning, men när de väl upplevt är det mycket mindre troligt att de blir smärtsamma igen. Den ökade utvecklingshastigheten, renare och smalare kod och det övergripande ramverket som uppmuntrar till bättre MVVM är mer än värt det för mig.
Caliburn.Micro ogiltigförklarar inte heller lager WPF – det bygger bara på det, vilket innebär att du fortfarande kan använda WPF-funktioner om du vill och använda Caliburn för några bitar om du vill. Detta liknar hur TypeScript och JavaScript samexisterar i mina tankar.
Jag skulle absolut använda Caliburn.Micro i alla nya WPF-projekt jag jobbar med i framtiden om jag får chansen.
Kommentarer
- Tack för ditt svar. Två år senare fann jag mycket lättare att ” acceptera ” dessa ramar efter att ha förstått begreppet Dependency Injection Containers, vilket jag lärde mig från utmärkt Mark Seeman ’ s ” DI i .NET ” bok.
Svar
För alla som kommer hit av frustration över Caliburn.Micro, ta en titt på detta ramverk: Stylet
Den är inspirerad av Caliburn.Micro, förutom att den tar bort mycket magi som gör att du är desorienterad om vad som händer. Dessutom är dokumentationen skriven på mycket tydligare språk utan att du antar att du vill vada genom teknisk jargong. Mycket bättre för nybörjare.
Stylet tar också ett ViewModel-First-tillvägagångssätt. Caliburn.Micro och många andra ramar tar ett View-First-tillvägagångssätt, vilket kommer med några besvärliga problem. Om du redan är mycket bra på SOLID-principer och mönstrad kod, kommer du sannolikt att hitta ett ViewModel-First-tillvägagångssätt mer naturligt eftersom det tar perspektivet att din logik ska driva systemet – inte vyn.
EventAggregatorför meddelanden ochNotificationObjectför en ViewModelBase och MVVM Light ’ sRelayCommandför kommandon. Det viktiga är att identifiera vilka problem ramverket kommer att lösa för dig, och bara använda dessa lösningar. Känn dig inte ’ som att du ’ tvingas använda hela rambiblioteket.RelayCommandimplementering (eftersom den ” binder ” direkt till metoder enligt konvention, istället för att binda till ICommand-egenskaper).RelayCommandfrån ett annat bibliotek om det som används av Caliburn Micro inte fungerar för dig.