WPF, UWP és Design Pattern-ek (pl. MVVM)
2020-05-13T15:02:43+02:00
2020-05-29T02:55:57+02:00
2022-07-20T15:02:11+02:00
  • Ha jól értem, akkor arra célzol, hogy kell Async Command is. :)
    Köszönöm szépen a választ!

    Próbáltam egy nem-Async Command-ot párosítani egy Async metódussal és látszólag úgyis lefut. Akkor az nem teljesen működik párhuzamosan, elkülönítve az UI-tól?

    public ICommand TestNormalCommand { get { if (_testNormalCommand == null) { _testNormalCommand = new NormalCommand(async _ => await DownloadStringAsync()); } return _testNormalCommand; } }



    (A DownloadStringAsync() egy Async Task, a NormalCommand pedig egy sima, nem-Async-es Command-ot.)
    Mutasd a teljes hozzászólást!
  • await-async párban jár :)
    Mutasd a teljes hozzászólást!
  • Async feladatok ellátásához (pl. weboldalról való adatok/string-ek letöltéséhez vagy egyéb, nem UI-al kapcsolatos adatok feldolgozásához) szükséges készíteni Async Command-okat? Vagy elég csak sima Async metódusokat létrehozni?

    (Elnézést a sok kérdésért.)
    Mutasd a teljes hozzászólást!
  • Köszönöm!
    Mutasd a teljes hozzászólást!
  • A szín logikusan azt jelenti, hogy valamilyen státusz más, vagyis a VM értelmezése, tehát a VM adataitől függő dolog.
    Az hogy színezés vagy más, azt esetleg konverterrel is megoldhatod, de az információ forrása a VM szokott lenni.

    Néha (pl. aktív mező kiemelése) a színezés független a VM-től, hiszen a View státuszától függ, ami -pont az a lényeg- hogy független a VM állapotaitól.

    Ezt neked kell eldöntened, a megjelenítendő dolog az View vagy VM függőség.
    Mutasd a teljes hozzászólást!
  • Még azt szeretném kérdezni, hogy pl. egy Label-nek a színváltoztatását lehet XAML kódban megírni vagy azt is inkább a ViewModel és Model részekben szokták leírni?

    Pl. van a Minimize (tálcára lerakás) és az ablak bezárásának a gombja. Ezeknek a gomboknak (Label-eknek), a színét akkor változtatja meg XAML-ben a kód, ha pl. ráviszem az cursor-t (tehát MouseOver esetén), illetve ha megszűnik ez a MouseOver event. Ezt egy Style-al oldottam meg.

    Kép:
    https://i.imgur.com/X3YcET8.png

    Ez esetleg jó megoldás az MVVM pattern szerint? Vagy inkább csináljak rá saját Command-ot/függvényt? (Tudom, hogy azt írtad, hogy UI-specifikus részeknél használható a code behind,  csak ilyen eseteknél nem tudom, hogy inkább C# kódot szoktak-e használni vagy XAML Style-t.)
    Mutasd a teljes hozzászólást!
  • Köszönöm szépen!
    Mutasd a teljes hozzászólást!
  • Én úgy gondolom, hogy egyáltalán nem ördögtől való code behind-ot használni UI-specifikus részekre, tehát ahol a UI változása teljesen független a mögöttük levő modelltől (ilyen pl. egy videólejátszót vezérlő kód nálam).

    Tehát a válasz: nem, egyáltalán nem kell mindenáron beleszuszakolni mindent a pattern-be.

    Persze, vékony a mezsgye: elképzelhető, hogy pl. szükséged van az ablak állapotára valamelyik modellben, mert ettől függ a működés is.

    Ilyen komplexebb esetben célszerűbbnek tűnik valamilyen Messenger megoldást alkalmazni, tehát az ICommand segítségével üzenetet küldesz a code behind-nak, ami elvégzi az UI specifikus változtatásokat. A cél pont az, hogy ne legyen közvetlen referencia a UI-ra. Persze vigyázni kell ezzel a megoldással, mert ha nem csak ott használod, ahol tényleg szükség van rá (mint pl. itt), könnyen követhetetlen, karbantarthatatlan kódot eredményez.

    Javaslom, vedd az időt, és nézd végig a javasolt MVVM Light modult, mert többek között erről is szó van benne. Valószínűleg találsz majd ott egyéb hasznos eszközöket is.
    Mutasd a teljes hozzászólást!
  • MVVM pattern-nél mennyire "kötelező" a Model-ben elvégezni a műveleteket?

    Mert saját készítésű ablakon (tehát nem alap Windows-oson) ügyködöm és szeretnék hozzá Minimize funkciót (azaz olyan funkciót, amivel lerakja tálcára az ablakot).
    Ezt úgy oldottam meg, hogy írtam egy WindowState típusú, CurrentWindowState nevű property-t, ami visszaadja az ablak jelenlegi státuszát (azaz, hogy most le van-e rakva tálcára vagy nem), és az XAML fájlban pedig Binding segítségével van összekötve a felülettel. 
    Nos, új command létrehozásánál először megpróbáltam, hogy a Model-ből hívok meg egy új függvényt és annak segítségével változtatom meg ezt a property-t, ámde közben kiderült, hogy a poperty elé nem lehet "ref" jelzőt rakni, tehát nem bírtam átadni a WindowState.Minimized értéket a Model-ből.

    Jelenleg úgy oldottam meg, hogy még az elején készítettem egy Update nevű függvényt (a ViewModel-en belül abban a Class-ban található, ahol a RaisePropertyChangedEvent függvény is van, azaz az event-ekért felelős Class-ban), ami arra szolgál, hogy "frissítse" a Property-ket, köztük a CurrentWindowState property-t (és vele együtt a _currentWindowState nevű változót) is, és ezt használtam fel arra egy Command-ban, hogy működjön a Minimize funkció.

    Készítettem pár screenshot-ot, hogy érthetőbb legyen a kérdésem:

    Az ViewModel-hez tartozó eventkezelő:
    https://i.imgur.com/4Nla5mN.png

    ViewModel: (Természetesen az előzőből van származtatva. Ezen a képen a CurrentWindowState property-t és a MinimizeMouseClickCommand nevű függvényt kell nézni.)
    https://i.imgur.com/BbxNmn9.png

    Model: (Itt csak azt szemléltetem, hogy hogyan próbáltam megoldani, a MinimizeMouseClick függvény segítségével.)
    https://i.imgur.com/sterrSM.png

    Tehát az lenne a kérdésem, hogy így meg lehet oldani? Vagy az MVVM pattern alapján inkább valahogy a Model-ben kellene megoldanom az értékátadást?
    Mutasd a teljes hozzászólást!
  • Mi azert valtottunk wpf-re hogy kihasznaljuk az elonyeit es nem azert mert azt irtak az interneten, hogy az a jovo. Biztos van sok ilyen 'winforms' project webes vonalon is, pont ezert nem akarok belemaszni egy legacy projektbe.

    Es persze maradnek a vas kozeleben (backend) szoval ilyen bongeszos angularos cuccokat egyelore bottal se piszkalnek meg.
    Mutasd a teljes hozzászólást!
  • Köszönöm a választ!
    Mutasd a teljes hozzászólást!
  • Értelemszerűen. Ha a CanExecuteChanged-ről nem akarod tájékoztatni a View-t (mert pl. a CanExecute konstans true, akkor nem valósítod meg.

    Én szeretem a ViewModelbe vinni az összes View státusz változást. 
    (Ha ez a triviálison túl mutat, akkor a "valódi" viewmodel-ből származtatok le egy olyan viewmodel-t, ami a hagyományos adatszerkezeten túl a státust (szövegek, láthatóság, enabled, műveletek stb) is tartalmazza.

    Vagyis én a user interakciót átvezetem a VM-en és onnan jelenik meg a View-ban.
    Mutasd a teljes hozzászólást!
  • Az MVVM pattern-nel kapcsolatban még olyan kérdésem lenne, hogy pl. ICommand létrehozásánál szükséges leírni a CanExecute metódust és a CanExecuteChanged eventet?
    Mert találtam egy példát az MVVM pattern-re itt: MarkWithall/worlds-simplest-csharp-wpf-mvvm-example, viszont a CanExecute-nál csak simán true értéket ad vissza, a CanExecuteChanged event-nél pedig teljesen üres az "add" és a "remove".

    Ezen az oldalon: RelayCommand ICommand event WPF MVVM pedig kezelve van a CanExecute és a CanExecuteChanged event is. Illetve itt is kezelve van: Patterns - WPF Apps With The Model-View-ViewModel Design Pattern

    Illetve még olyan kérdésem lenne, hogy MVVM pattern-ben a UI eventeket (mint pl. "MouseEnter", "MouseLeave", "MouseLeftButtonUp", stb.), ugyanúgy command-ekkel kell kezelni, mint pl. egy sima button megnyomását?
    Mutasd a teljes hozzászólást!
  • Hát nekem kellett már WPF projectet javítanom, ami WinForms-szerűen volt telerakva eseménykezelőkkel, direkt referenciákkal, abszolút pozíciókkal, a code behind pedig állt vagy 5000 sorból.

    Na, ilyen az, amikor a tipikus fejlesztő leül, hogy ide elém azt a WPF-et, mi újat tud ez nekem nyújtani. Nem te szívsz vele, hanem akinek karban kell majd tartania azt.

    Nem atomfizika az Angular, de azért van tanulási görbe, ha nem gányolni akarsz; pl. az RxJS helyes használata elég komoly paradigmaváltás, a 100+ fölötti operátorával.
    Mutasd a teljes hozzászólást!
  • A winforms->WPF váltást se sürgettem, egyszer csak jött egy zöldmezős project, ahol ezt kellett használni, előtte picit képeztük magunkat, majd beleugrottunk és ennyi. (a mostani zöld mezős egyelőre WPF és térinformatika terület). Azelőtt meg valahol a pályám elején pont PHP-ról ugrottunk a winforms-ra egy project kapcsán, szóval nincs ez kőbe vésve és attól se félek, hogy éhenhalok. Azért a fejlesztői tapasztalat ott van, nem most kell a for ciklust megtanulni, de olyan tragikusan fogalmazol, mintha ez lenne a tényállás.

    Ezek mellett C/C++ al, meg 3D grafikával is foglalkozom. Arra sincs sok állás, de azért hasznát veszem a mostani céges projectben is többek között.
    Mutasd a teljes hozzászólást!
  • Jövő héten már production ready lesz :) Jön a build conference és elvileg ott adják ki a véglegest, az RC már elérhető két hete.
    Mutasd a teljes hozzászólást!
  • Jelenleg szerveroldalit.
    A kliens még nem production ready.
    Valamint a szerver oldalon a debug is sokkal egyszerűbb továbbá nem kell egyelőre foglalkozni a kliens-szerver közötti adatforgalommal.
    Szóval kényelmes.
    A cél persze a wasm-es klienses, de valószínűleg azután is megmarad, hogy először szerveroldalival belövöm, aztán átteszem kliens oldalra (megvalósítva a C/S adatforgalmat, de a már belőtt üzleti logika és view működésből a szervert érintrő rétegre. Persze alapból úgy kell rétegezni, hogy tudja az ember, hogy itt lesz kettévágva.

    Továbbá néztem, a későbbiekben az egybegyógyított MVC&WASM-Blazor is érdekes lehet.

    A MatBlazor-t használom, nekem egyszerűbb komponensek is megfelelnek és szabadabban átalakíthatónak, bővíthetőnek találtam, ha egyedi elvárásaim teremnének. Valamint "szabálykövetőbbnek" (érts kevésbé erőszakolja meg a html/css alapokat) mint a syncfusion.
    Mutasd a teljes hozzászólást!
  • Bocs ha off topic, de ha már szóba jött az Angular, szeretném kérdezni azoktól akiknek van benne tapasztalata, hogy releváns JS tudás nélkül mennyire lehet eredményesen elmélyülni az Angularban?
    Mutasd a teljes hozzászólást!
  • Választottál hozzá valami komponens gyűjteményt? Ha igen, melyiket?
    Server vagy kliens oldali renderinget használsz?
    Mutasd a teljes hozzászólást!
  • Az Angular/TS páros még egész civilizált (bár akkor is fáj a transpiler, és azért ott is akadnak csúnyaságok) de tudod, nem az Angular a legelterjedtebb webes framework...
    Mutasd a teljes hozzászólást!
  • Másrészt ott a Blazor, igaz csak most csinálom az első kísérleti-de éles projectet (megtehetem, házon belüli) ahol MVC, MVVM és C#/.Net teljes ereje egyben.... elég ütősnek tűnik :)
    Mutasd a teljes hozzászólást!
  • Szóval hajrá, nem kell annyira félni tőle.

    igazából annyi mindent csinálok egyszerre, hogy nem érzem a szükségességét. Meg egyszer már voltam benne - rossz tapasztalat - és ezt elég nehéz leküzdeni úgy, hogy igazából "komoly" késztetés nincs rá.

    De mindettől függetlenül tudom, hogy kell. Rajta van a listán :) 

    Persze tanulhatnám most is, de inkább gitározni tanulok. Még élvezem is, bár látom, hogy ezt is gyerekként kellett volna elkezdeni
    Mutasd a teljes hozzászólást!
  • Ettől még senkinek se ajánlanám, hogy ezzel kezdjen vagy karriert építsen rá mert értelmetlen.

    szerintem ezekből a hozzászólásokból a kérdező majd eldönti mit akar.

    kicsit visszanézve a pályámat én ZX spectrum Basic/Assembly-vel kezdtem
    utána jó sokáig turbo pascal
    majd egy egy hirtelen váltással DTP (photoshop, quark, illustrator) mindezt Mac-en
    hogy aztán visszakanyarodjak a HTML+Javascript világába
    Majd Flash és akkor még Macromedia Director
    Közben egy nagy adag 3d (Max, Lightwave, maya)
    2008-tól c# és 2010-től wpf
    Aztán egy kis C és nagy adag CUDA
    Most meg Neural Network, c# wpf + 3d modo
    meg persze unreal blueprint és pici C++
    Ja és minimális pájton mert az NN hozza magával

    Szerintem pont tökmindegy, hogy mivel kezd. A lényeg, hogy rugalmas legyen
    Biztosra veszem, hogy a legtöbbünk pályája kb ehhez hasonló kacifántos móka.

    Amit ma tutira veszel, az holnapra lehet, hogy elavult.
    De akkor is adott valami olyan tudást, amit át tudsz vinni,


    És igen. Igazad van neked is, meg mindenkinek.
    Ha olyan tudást akarsz, amivel holnap már pénzt keresel biztosan, akkor menj webre.
    Azzal tuti, hogy nem mész félre
    Mutasd a teljes hozzászólást!
  • Még annyit hozzátennék, hogy tökéletesen megértem az idegenkedést a webes világtól, hiszen magam is átmentem ezen, de ez még egy olyan korból származik, amikor procedurális, strukturálatlan scripthalmaz, minden böngészőben másképp működő layout jelentette a webes fejlesztést.

    ES2015 óta (mindössze 5 éve, mondjuk ez vicces) a JS nagykorúvá érett, gyakorlatilag egy Angular/TypeScript párosban pont ugyanolyan elvek mentén fejlesztesz, mint egy WPF app-ban, csak más a szintaktika. Ugyanúgy van a binding, DI, modellek, view-k, service-ek, osztályok, interface-ek, tesztek stb.

    Persze még mindig olyan érzés, mint amikor az ember idegen nyelven fogalmaz a sajátja helyett (nekem legalábbis ez nem természetes), és az ember néha a haját tépi a JS következetlenségei, alap hiányosságai miatt, de végre nem az összetákoltság érzete lengi körül, mint tette 10-15 éve.

    Bevált standard lib-ek, framework-ök vannak, amivel mezei fejlesztőként zéró UI design tudással, néhány sorral is szép, modern kinézetű, gyors app-ot lehet létrehozni, ami nem csak az egyre zsugorodó Windows platformon fut, hanem bárhol. Nem véletlen a Microsoft irányváltása.

    Szóval hajrá, nem kell annyira félni tőle.
    Mutasd a teljes hozzászólást!
  • Winforms, wcf és társai. Ezzel jobban mellé lehet.

    On side related note, szerintem Winfoms kód több van mint van mint WPF.
    Nekem is van Winforms szoftverem amit még fejlesztgetek, vagy legalább próbálok úgy tenni mintha lennének új dolgok benne, mert elég sok pénzt hoz és veszik a terméket de ezt a munka mellett. Ettől még senkinek se ajánlanám, hogy ezzel kezdjen vagy karriert építsen rá mert értelmetlen.
    Mutasd a teljes hozzászólást!
  • Oké ebben egyet értünk.
    De.
    Juniorként egy nagy nemzetközi cégnél "tákolni" a kódot és belelátni egy nagy rendszerbe nem olyan rossz dolog.

    Persze átgondolva pályakezdőként lehet én is a web irányába mozdulnék

    A topicnyitó pedig kifejezetten wpf, uwp párost kérdezte.
    Ezzel mobiltelefonon is el lehet lenni, az pedig nem most fog kihalni.
    Aztán lássuk mit hoz a web az opensilverrel
    Mutasd a teljes hozzászólást!
  • nem találunk embert winformsra, mindenki webezik

    Na, de szerinted miért?

    Ez a szakma olyan gyorsan változik, hogy ha nem a legújabb cuccokkal dolgozol, gyorsan a pálya szélén találod magad. Ahol WinForms kell, az egy ómen. Majd lehet, visszamegyek én is WinForms-ozni 10-15 év múlva, aztán csilliárdokat keresek a Cobol fejlesztők mintájára.

    Az belefér, hogy ha egy cég modernizálni akar, és ezért kell, hogy a legújabb technika használata mellett képes legyen WinForms kódot olvasni, karbantartani, de ilyet dedikáltan fejleszteni?

    Te specialista vagy, ugyan annak is vannak kockázatai a szűkebb lehetőségek miatt, de valószínűleg neked nem lesz elhelyezkedési problémád a tapasztalatod miatt. Ugyanakkor pályakezdőként veszélyes lehet egy ennyire bizonytalan jövőjű területre specializálódni.
    Mutasd a teljes hozzászólást!
  • Persze ez a te döntésed csak ne mondjuk egy pályakezdőnek, hogy nem nyúlhat mellé mert kb. nehezebb lenne .net fronton mással jobban mellényúlnia.

    Winforms, wcf és társai. Ezzel jobban mellé lehet.
    Csak a miheztartás végett idézek egy kb 5 napos beszélgetésből a haverommal: bazz nem találunk embert winformsra, mindenki webezik

    Még rengeteg hely van, ahol ezeket a technológiákat használják. Az, hogy Te nem tudsz róla, az egy dolog.
    Mutasd a teljes hozzászólást!
  • hogy a 3 pozícióban biztos 10-15 éves rendszereket kell barkácsolni, bugot vadászni bennük, más összekókányolt kódját egyengetni és úgy kb. nulla az újdonság.

    a 3-ból egyikben 5 évig dolgoztam. Konkrétan én kókányoltam össze a WPF UI alapjait. Aztán persze még 4 kollega segített. Ma már nem tudom milyen lehet, mert 2 éve nem vagyunk ott.

    Ja és ha van hely, ahol aztán van újdonság, akkor ez az.
    Kb 1000 különféle fizikai mérőműszerük van. Azért piszok jó érzés amikor egy 1.5M Eur gép elindul és az csinálja amit akarsz.
    És itt a UI nem merült ki abban, hogy jeleníts meg a lekért adatból 30 sort. Piszok extrém kontrolokat kell írni.

    Nem mellékesen ha érdekel akkor tudsz CUDA-zni (én vezettem be ezt is, csak hogy felvágjak, utána már volt 1 segítségem - bár ez relatív, mert pillanatok alatt Ő lett a mester), valamint Neural Networközni - ennek bevezetésében csak részt vettem :)
    Messze nem rossz dolog kódot írni, ami egy ekkora monstrumot vezérel plusz analízist csinálni a mért adatokhoz.

    Ismerve azt a rendszert pusztán a mérete miatt nem lesz egyhamar webre portolva.
    Másfelől vannak világok (elképesztően nagyok, elképesztően sok) ahol a web nem pálya. Meg a cloud se. Írtóznak attól, hogy a privát adataik a gyár kapuján kivülre jussanak.

    Mindazok, akik itt dolgoznak(tak) 1 dologban hasonlóak voltak: csak webhez ne kelljen nyúlni.
    Mutasd a teljes hozzászólást!
  • Tegyük hozzá azt is, hogy a 3 pozícióban biztos 10-15 éves rendszereket kell barkácsolni, bugot vadászni bennük, más összekókányolt kódját egyengetni és úgy kb. nulla az újdonság.
    Tehát ha váltanál is akkor is egy kaksi kupac tetejéről átülhetnél a másik tetejére kapirgálni de nem kell másik tízzel versenyezned érte, az tény :)
    Mutasd a teljes hozzászólást!
abcd