Jednou jsem zahájil projekt MVVM / WPF, který byl nakonec postaven a nasazen, a za tímto účelem jsem studoval mnoho rámce Caliburn.Micro MVVM. Faktem je: skončil jsem ne pomocí Caliburn.Micro a nakonec jsem implementoval některé koncepty MVVM sám (konkrétně ViewModelBase a RoutedCommand tříd).
Nyní jsem byl přidělen k poněkud většímu projektu ve stejném duchu: a “ Single-User Bohatá klientská offline aplikace pro počítače „, abych tak řekl, a rozhodl jsem se použít Caliburn.Micro. A tím začíná můj “ problém „.
Četl jsem v tento slavný blogový příspěvek , jehož název říká, že “ Pokud používáte MVVM, pak potřebujete rámec „, který:
“ Pokoušet se udělat něco jako MVVM bez rámce je obrovské množství práce. Tuny duplicitního kódu, objevování nového kola a rekvalifikace lidí, aby mysleli jinak .
Alespoň s rámec, kterému se vyhnete duplicitnímu kódu a doufejme, že nemusíte znovu objevovat kolo – což vám umožní soustředit se na rekvalifikaci lidí. Část rekvalifikace je obecně nevyhnutelná, ale rámec poskytuje instalatérský kód a strukturu, což usnadňuje proces. “
Souhlasím s prvním přečtením, ale moje skutečné zkušenosti s Caliburn.Micro (CM) v mé skutečné aplikaci je bezradnost a dezorientace. To znamená, že rámec tento proces vůbec neusnadnil, právě naopak. Čtením stále se opakujících příkladů poskytovaných Robem Eisenbergem v poněkud (příliš) neformální dokumentaci a snahou vyvodit vzorce použití ze spletitých poskytnutých vzorků, a jejich naprosto nepřímé vztahy mezi třídami a rozhraními, kde se věci zdají být navrženy tak, aby fungovaly na základě vedlejších účinků, se lidsky jeví jako nemožné, pokud nejste ostříleným géniem (omlouvám se za rant, ale myslím, že víte co tím myslím).
Nemluvě o tom, že se zdá, že jakýkoli výše triviální scénář zahrnuje kontejnery IoC, což je něco, s čím jsem nikdy nepracoval, a zdá se, že Vyřešit problém, který možná ani nemám . Nemám pocit, že bych se věcem věnoval více projektových hodin místo přemýšlení o mých problémových a aplikačních doménách. Chtěl jsem jen banán, ale CM mi dal gorilu (IoC), která držela koš banánů.
Teď, když uvažuji o návratu zpět k mému domácímu rámci MVVM – složenému pouze z hrstky MVVM- konkrétní třídy, které vlastně chci implementovat – chtěl bych dát alespoň šanci CM, pokud tu něco ztratím, nebo prostě dělám věci “ špatně “ z naprosté nezkušenosti a nevědomosti. Otázka tedy zní:
Existuje všeobecná shoda v tom, že “ rámce usnadňují a přirozenější věci „, ale pokud náhodou zažívám pravý opak, znamená to, že bych rámec neměl používat, nebo že se ho snažím naučit špatně? Existuje nějaká tuším, že bych vůbec neměl používat framework? Nebo existuje nějaký “ pravý “ způsob, jak zjistit, jak použít CM pro jednoduchý vývoj MVVM?
Komentáře
Odpověď
Zkoušel jsem CaliburnMicro a MVVMLight a když používám Caliburn, opravdu cítím to, co cítíte, určitě se cítíte opravdu magicky schopný vázat ovládací prvek na vlastnost pouhým použitím Name = “ PropertyName “ místo starého Text = “ {Bind PropertyName} “ ale nakonec Caliburn půjde přes palubu, aby tuto magickou věc udělal . Když se něco pokazí, je opravdu těžké ladit a aby to nebylo ještě horší, mají spoustu způsobů, jak udělat jednu věc.
Naproti tomu je MVVMLight opravdu tenký. Když jej použijete, pravděpodobně si uvědomíte, že je téměř 100% jako váš rámec MVVM, v němž je obsypána nějaká funkce.
Vím, že to na vaši otázku neodpovídá “ Jak NEPOUŽÍVAT framework „, ale upřímně vám nemohu doporučit jít touto cestou. Myslím, že jste ztraceni, protože jste místo toho nejprve použili plně vybavený rámec.
Komentáře
- Myslíte si tedy, že bych se měl alespoň pokusit použít MVVMLight jako nějakou řadu “ léčení “ z “ Caliburn.Micro dezorientace „? Určitě bych se podíval, jestli tomu tak je.
- @heltonbiker Určitě to zkuste. Je to mnohem jednodušší, alespoň by vám mělo dát dobrou oporu v MVVM Framework.
- Souhlasím, že se děje příliš mnoho magie. Předpokládám, že pochází z pozadí c a sestavy. E něco nebude ‚ pracovat jen proto, aby to našel díky magii v pozadí. Nelze ladit a pokud máte problémy s výkonem, často toho moc neuděláte.
Odpovědět
Je důležité si uvědomit, co je MVVM. Nejedná se o nějaký sdílený bit funkcí, který nemusíte znovu implementovat (analýza souboru JPEG nebo připojení k danému databázovému serveru SQL), jedná se o vzor – vzor pro výběr implementovat bohaté grafické uživatelské rozhraní. Pokud je tedy vaše implementace vzoru jednoduchá a přímočará, nemyslím si, že byste při jejím používání měli cítit nějakou hanbu, spíše než rámec.
Ve skutečnosti věřím, že celá myšlenka vzorů jako rámců má zašel příliš daleko. Aby něco mohlo být vzorem, musí to být obecný tvar třídy řešení. Protože tomu tak je, lze očekávat, že vzory budou muset být přizpůsobeny systémům, které je používají, a to nemůžete udělat, pokud se pokusíte použít univerzální vzor. Bylo by mnohem konstruktivnější ponechat implementaci vzorů na návrháři aplikací a poskytnout knihovny, které zapouzdřují funkčnost, nikoli architekturu.
Komentáře
- Přidáno do že MVVM, jak jej nabízí Microsoft (mimo krabici, WPF), velmi chybí. Velmi frustrující i pro programátory, kteří se považují za sebe (a oprávněně) za ostřílené vývojáře. Magické řetězce, nejasné výjimky za běhu, nejzákladnější věci, jako je navázání skupiny radiobuttonů na výčet, vypadají jako stackoverflow.com/q/397556/168719 – co mohou rámce dělat? Musí buď zopakovat tuto úroveň složitosti, nebo se o to pokusit poskytnout opravdu silnou abstrakci.
- @KonradMorawski WPF samo o sobě není MVVM; můžete udělat kód za sebou s WPF, ale ‚ to není MVVM. Takže pokud chcete dělat WPF a MVVM, musíte ‚ použít rámec MVVM nebo si jej sami implementovat.
- @Andy samozřejmě, ale ‚ s jistotou lze říci, že WPF je určen pro MMVM.‘ m odkazuji na funkci MVVM, která je integrována do WPF. Vím, že můžete stále dělat kód za sebou.
- @KonradMorawski Můžete použít WPF s MVVM a postavili ho s ohledem na tuto možnost ve víře, ale ve WPF není zabudována ŽÁDNÁ specifická funkce MVVM. Stejně jako můžete použít MVP s WinForms, ale WinForms nenabízí nic konkrétně pro použití tohoto vzoru, záleží jen na vás.
- @Andy možná se ‚ znovu hádáme definice nyní. Mám na mysli to, že “ lepidlo „, které umožňuje použití MVVM, již existuje – datové vazby v XAML,
DataContextatd.
Odpověď
Moje první zkušenost s WPF byla používání Caliburn. Micro, takže toto je pravděpodobně docela odlišné od většiny vývojářů. Zjistil jsem, že WPF i Caliburn.Micro jsou docela strmá křivka učení, vycházející z WinForms, ale po nějaké zkušenosti s oběma jsem jim našel potěšení použít jako pár. V současné době pracuji v jiné organizaci, kde se Caliburn.Micro nepoužívá. Zjistil jsem, že existuje spousta duplicitních instalatérských kódů, díky nimž je základna kódu docela nafouknutá a zbytečně složitá.
Rozhodně souhlasím s tím, že existují nějaké gotchas s Caliburn.Micro, což může zkomplikovat ladění, ale jakmile se jednou objeví, je mnohem méně pravděpodobné, že bude znovu bolestí. Zvýšená rychlost vývoje, čistší a štíhlejší kód a celkový rámec podporující lepší MVVM pro mě více než stojí za to.
Caliburn.Micro také neznehodnocuje základní WPF – staví se jen na jeho vrcholu, což znamená, že pokud chcete, můžete stále používat funkce WPF a pokud chcete, můžete použít Caliburn na pár kousků. To je podobné tomu, jak v mé mysli koexistují společně TypeScript a JavaScript.
Rozhodně bych použil Caliburn.Micro v každém novém projektu WPF, na kterém v budoucnu budu pracovat, pokud dostanu šanci.
Komentáře
- Děkujeme za odpověď. O dva roky později mi bylo mnohem jednodušší “ přijmout “ tyto rámce poté, co jsem pochopil koncept Dependency Injection Containers, který jsem se naučil z vynikající Mark Seeman ‚ s “ DI v .NET “ knize.
Odpověď
Pro každého, kdo sem přijde z frustrace z Caliburn.Micro, podívejte se na tento rámec: Stylet
Je inspirován programem Caliburn.Micro, kromě toho, že odstraňuje spoustu magie, která vás dezorientuje v tom, co se děje. Dokumentace je navíc napsána v mnohem jasnějším jazyce, aniž byste předpokládali, že se budete chtít projít technickým žargonem. Mnohem lepší pro začátečníky.
Stylet také používá přístup ViewModel-First. Caliburn.Micro a mnoho dalších frameworků využívá přístup View-First, který přichází s některými nepříjemnými problémy. Pokud jste již velmi dobří v principech SOLID a vzorovaném kódu, pravděpodobně vám bude přístup ViewModel-First připadat přirozenější, protože má perspektivu, že vaše logika by měla řídit systém – ne pohled.
EventAggregatorpro zasílání zpráv aNotificationObjectpro a ViewModelBase a MVVM Light ‚ sRelayCommandpro příkazy. Důležité je zjistit, jaké problémy rámec pro vás vyřeší, a používat pouze tato řešení. Nenechte se ‚ cítit, že jste ‚ nuceni používat celou knihovnu rámců.RelayCommand(protože “ váže “ přímo na metody konvencí, místo vazby na vlastnosti ICommand).RelayCommandz jiné knihovny, pokud ta, kterou používá Caliburn Micro, pro vás nefunguje.