Olen kerran aloittanut MVVM / WPF-projektin, joka lopulta rakennettiin ja otettiin käyttöön, ja opiskelin sitä varten paljon Caliburn.Micro MVVM Frameworkia. Tosiasia on, että päädyin käyttämättä Caliburn.Microa siihen ja päädyin itse toteuttamaan joitain MVVM-käsitteitä (erityisesti ViewModelBase ja RoutedCommand luokat).
Nyt minut määrättiin jonkin verran suuremmalle projektille samalla linjalla: a ” Yhden käyttäjän Rich Client Offline Desktop -sovellus ”, sanoin, ja päätin käyttää Caliburn.Micro-sovellusta. Ja siitä missä ” -ongelmani ” alkaa.
Olen lukenut osiosta tämä kuuluisa blogiviesti , jonka otsikossa sanotaan, että ” Jos käytät MVVM: ää, tarvitsee kehys ”, joka:
” MVVM: n kaltaisen yrittäminen ilman kehystä on valtava määrä työtä. Tonnia päällekkäistä koodia, pyörän keksiminen uudelleen ja ihmisten uudelleenkouluttaminen ajattelemaan eri tavalla .
Ainakin kehys, jonka avulla vältät päällekkäisen koodin ja toivottavasti sinun ei tarvitse keksiä pyörää uudelleen – jolloin voit keskittyä ihmisten uudelleenkoulutukseen. Uudelleenkoulutusosa on yleensä väistämätön, mutta -kehys tarjoaa putkikoodin ja rakenteen, mikä helpottaa prosessia. ”
Olen samaa mieltä ensimmäisestä käsittelystä, mutta todellinen kokemukseni Caliburn.Micro (CM) -palvelusta varsinainen sovelluksessani on tietämättömyyttä ja hämmennystä. Toisin sanoen kehys ei tehnyt prosessia lainkaan helpommaksi, päinvastoin. Lukemalla Rob Eisenbergin jatkuvasti toistuvia esimerkkejä melko (myös) epävirallisessa dokumentaatiossa ja yrittämällä päätellä käyttötapoja sekoitetuista toimitetuista näytteistä, ja heidän täysin epäsuorat luokka- ja käyttöliittymäsuhteensa, joissa asiat näyttävät olevan suunniteltu toimimaan sivuvaikutusten perusteella , näyttävät inhimillisesti mahdottomilta, ellet ole kokenut nero (anteeksi pilkasta, mutta luulen, että tiedät mitä tarkoitan).
Puhumattakaan siitä, että mihinkään yli triviaaliseen skenaarioon näyttää liittyvän IoC-kontteja, mihin en ole koskaan työskennellyt ja jotka näyttävät ratkaise ongelma, jota minulla ei ehkä edes ole . En halua viettää enemmän projektituntia oppia noita asioita sen sijaan, että ajattelisin ongelmaa ja sovellusalueita. Halusin vain banaanin, mutta CM antoi minulle gorillan (IoC), jolla oli kori banaaneja.
Nyt, kun harkitsen siirtymistä takaisin kotikokoiseen MVVM-kehykseen – joka koostuu vain kourallisesta MVVM- tietyt luokat, jotka todella haluan toteuttaa – haluaisin ainakin antaa CM: lle mahdollisuuden, jos menetän jotain täällä tai teen vain asioita ” väärin ” pelkästään kokemattomuudesta ja tietämättömyydestä. Joten kysymys kuuluu:
On laajaa yksimielisyyttä siitä, että ” kehykset tekevät asioista helpompia ja luonnollisempia ”, mutta jos minulla on tapana päinvastoin, tarkoittaako tämä sitä, että minun ei pitäisi käyttää kehystä tai yritän oppia sen väärin? Onko olemassa vihje siitä, että minun ei pitäisi edes käyttää kehyksiä? Vai onko olemassa jokin ” oikea ” tapa selvittää, miten CM: tä käytetään yksinkertaiseen MVVM-kehitykseen?
Kommentit
Vastaa
Olen kokeillut CaliburnMicroa ja MVVMLightia ja kun käytän Caliburnia, tunnen todella, mitä sinusta tuntuu, että se tuntuu todella maagiselta pystyä sitomaan ohjausobjektin omaisuuteen vain käyttämällä Name = ” PropertyName ” vanhan Text = ” {Bind PropertyName} ” sijaan, mutta lopulta Caliburn menee yli laidan tekemään tämän maagisen asian . Kun jokin menee pieleen, on todella vaikea selvittää ja pahentaa asioita. Heillä on paljon tapoja tehdä yksi asia.
Sen sijaan MVVMLight on todella ohut. Kun käytät sitä, huomaat todennäköisesti, että se on melkein 100% kuin MVVM Framework, jossa on joitain ominaisuuksia.
Tiedän, että tämä ei ”vastaa kysymykseesi ” Kuinka kehystä ” ei saa käyttää, mutta rehellisesti sanottuna en voi suositella sinun kulkemista tällä reitillä. Luulen, että olet vain eksynyt, koska käytit täysin varustettua kehystä sen sijaan, että käyttäisit ensin yksinkertaista.
Kommentit
- Luuletko sitten, että minun pitäisi ainakin yrittää käyttää MVVMLightia eräänlaisena ” -lajitteluna ” joukosta ” Caliburn.Mikro disorientaatio ”? Katson varmasti, jos näin on.
- @heltonbiker Ehdottomasti, anna sille mennä. Se on niin paljon yksinkertaisempaa, että se antaa sinulle ainakin hyvän jalansijan MVVM-kehyksessä.
- Olen samaa mieltä siitä, että taika on liikaa. Tulen c- ja kokoonpanotaustasta. E jotain ei toimi ’ ei toimi vain löytääksesi sen taikuuden takia. Virheenkorjaus on mahdotonta, ja kun sinulla on suorituskykyongelmia, ei usein ole paljon, voit tehdä siihen helposti.
Vastaa
On tärkeää ymmärtää mikä MVVM on. Se ei ole jokin jaettu bitti toiminnallisuus, jota sinun ei tarvitse täydentää (JPEG-tiedoston jäsentäminen tai yhteyden muodostaminen tiettyyn SQL-tietokantapalvelimeen), se on malli – malli siitä, miten kukaan voi valita toteuttaa rikas käyttöliittymä. Joten jos mallisi toteuttaminen on yksinkertaista ja suoraviivaista, en usko, että sinun tarvitsee tuntea häpeää sen käytöstä pikemminkin kuin kehyksestä.
Uskon todellakin, että koko mallit-kehyksinä -ideolla on mennyt aivan liian pitkälle. Jotta mikä tahansa olisi malli, sen on oltava ratkaisuluokan yleinen muoto. Koska näin on, on odotettavissa, että mallit on räätälöitävä niitä käyttäville järjestelmille, etkä voi tehdä sitä, jos yrität käyttää yhtä kokoa kaikille. Olisi paljon rakentavampaa jättää mallin toteutus sovellussuunnittelijalle ja tarjota kirjastot, jotka kapseloivat toiminnallisuuden arkkitehtuurin sijaan.
Kommentit
- Lisätty että Microsoftin tarjoama MVVM (out of the box, WPF) puuttuu hyvin paljon. Erittäin turhauttavaa myös ohjelmoijille, jotka ajattelevat itsensä kokeneiksi kehittäjiksi. Maagiset merkkijonot, epäselvät poikkeukset ajon aikana, useimmat perustavat asiat, kuten ryhmän radiopainikkeiden liittäminen enumiin, näyttävät stackoverflow.com/q/397556/168719 voivatko kehykset tehdä? Heidän on joko toistettava tämä monimutkaisuuden taso tai yritettävä antaa siitä todella paksu abstraktio
- @KonradMorawski WPF itsessään ei ole MVVM; voit tehdä koodin takana WPF: llä, mutta se ’ ei ole MVVM. Joten jos haluat tehdä WPF: n ja MVVM: n, ’ sinun on käytettävä MVVM-kehystä tai toteutettava itse.
- @Andy tietysti, mutta se ’ on turvallista sanoa, että WPF on tarkoitettu MMVM: lle.
m viitaten MVP-toiminnallisuuteen, joka tulee sisäänrakennettuna WPF: n kanssa. Tiedän, että voit silti tehdä koodin takana
DataContext jne. Vastaa
Ensimmäinen kokemukseni WPF: stä on ollut Caliburnin käyttö. Mikro, joten tämä on todennäköisesti melko erilainen kuin useimmat kehittäjät. Olen havainnut sekä WPF: n että Caliburn.Micron olevan melko jyrkkä oppimiskäyrä, joka tulee WinFormsista, mutta kokemukseni molempien kanssa olen löytänyt heille ilon käyttää parina. Työskentelen tällä hetkellä toisessa organisaatiossa, jossa Caliburn.Microa ei käytetä. Huomaan, että siellä on PALJON päällekkäisiä LVI-koodeja, jotka tekevät koodipohjan melko paisuneeksi ja tarpeettoman monimutkaiseksi. kanssa Caliburn.Micro, mikä voi vaikeuttaa virheenkorjausta, mutta kokenut ne ovat todennäköisesti vähemmän kipuja. Lisääntynyt kehitysnopeus, puhtaampi ja kevyempi koodi ja yleinen kehys, joka kannustaa parempaan MVVM: ään, ovat minulle enemmän kuin sen arvoisia.
Caliburn.Micro ei myöskään mitätöi WPF-osaketta – se vain rakentuu sen päälle, mikä tarkoittaa, että voit silti käyttää WPF-ominaisuuksia, jos haluat, ja käyttää Caliburnia muutamalle palalle, jos haluat. Tämä muistuttaa sitä, miten TypeScript ja JavaScript ovat rinnakkain mielessäni.
Käytän ehdottomasti Caliburn.Microa kaikissa uusissa WPF-projekteissa, joissa työskentelen tulevaisuudessa, jos minulle annetaan mahdollisuus.
Kommentit
- Kiitos vastauksestasi. Kaksi vuotta myöhemmin minusta oli paljon helpompaa ” hyväksyä ” nämä kehykset, kun olen ymmärtänyt riippuvuuden ruiskutusastioiden käsitteen, jonka opin erinomainen Mark Seeman ’ s ” DI .NET ” -kirjassa.
Vastaus
Kaikille, jotka saapuvat tänne turhautuneena Caliburn.Micro -palveluun, katsokaa tätä kehystä: Stylet
Se on innoittamana Caliburn.Micro, paitsi että se poistaa paljon taikaa, joka jättää sinut hämmentyneeksi siitä, mitä tapahtuu. Lisäksi dokumentaatio on kirjoitettu yksinkertaisemmalla kielellä ilman, että olisit halunnut kahlata teknistä ammattikieltä. Paljon parempi aloittelijoille.
Stylet käyttää myös ViewModel-First-lähestymistapaa. Caliburn.Micro ja monet muut kehykset käyttävät View-First-lähestymistapaa, johon liittyy joitain hankalia ongelmia. Jos olet jo erittäin hyvä SOLID-periaatteissa ja kuvioidussa koodissa, todennäköisesti ViewModel-First-lähestymistapa on luonnollisempi, koska siinä otetaan huomioon, että logiikkasi ohjaa järjestelmää – ei näkymää.
EventAggregatorviestiä varten jaNotificationObjecta ViewModelBase ja MVVM Light ’ sRelayCommandkomentoille. Tärkeää on tunnistaa, mitä ongelmia kehys ratkaisee sinulle, ja käyttää vain näitä ratkaisuja. Älä ’ tunne, että sinun ’ on pakko käyttää koko kehyskirjastoa.RelayCommand-toteutusta (koska se ” sitoo ” suoraan menetelmiin sopimuksella sen sijaan, että se sitoutuisi ICommand-ominaisuuksiin).RelayCommandtoisesta kirjastosta, jos Caliburn Micron käyttämä kirjasto ei toimi sinulle.