C#/.NET - Több rétegűek a WPF/WinForms alkalmazások?
2015-07-21T15:01:40+02:00
2015-07-23T11:49:15+02:00
2022-07-22T07:06:44+02:00
  • EF 7-et is új alapokra helyezik, ott már csak code first van.

    Ami ugye csak a reprezentáció módja?

    CodeFirst-ből adatbázis séma, adatbázis sémából CodeFirst definíció.
    Oda vissza konverzió a leghatékonyabb, ez is egyfajta "kétirányű fejlesztést"(*) tesz lelehetővé.

    (*) a Borland marketing varázsszava volt az IDE-created/code-edit párhuzamra.
    Mutasd a teljes hozzászólást!
  • Az utolsó ahol még vizuálisan írtad le, a windows.forms

    Azért ezt a kijelentést egy kicsit árnyalnám: az újabb VS-k beépített designer-ével ill. a hozzáadott Blend-del ha nagyon nem fekszik az UI kódírás, a legkomplexebb dolgokat is összekattintgathatod (pl. adatkötések stb.), bár a tutorial-videókon én elvesztem a százmillió lehetőség között, ennél néha egyszerűbbnek tűnik beírni kézzel, amit az ember akar.

    Részemről egyébként kombinálom ezeket: néhány megjegyezhetetlen szintaxisnál behúzom egérrel a kívánt elemet, viselkedést stb., hagyom, hogy legenerálja a kódot a designer, és utána kézzel kitisztítom és testre szabom.

    De ha nagyon akarod, WPF alatt pont úgy tudsz szerkeszteni, mint Forms-nál, pixelre húzogatni az elemeket stb., más kérdés, hogy ez nem ajánlott.

    sőt mintha hallottam volna olyat is, hogy hosszú távon a designer meg is fog szűnni.

    Konkrétan: EF 7-et is új alapokra helyezik, ott már csak code first van. EF 6-nál még elérhető minden (db first, model stb.).
    Mutasd a teljes hozzászólást!
  • Hát nem. Lásd html, xaml. Pont hogy nem vizuálisan írod le, hanem szépen kóddal mint a 70-es, 80-as években. Az utolsó ahol még vizuálisan írtad le, a windows.forms volt, illetve régebben a Delphi és a VB.

    nekem nem is igazán tetszik ez az irány
    Mutasd a teljes hozzászólást!
  • Nekem speciel nem jön be az, hogy vizuális tartalmat is kóddal kell leírni, sőt manapság inkább ennek fordítottja a trend, vagyis a logika kódját is vizuálisan írják le, de üzleti alkalmazásoknál ez annyira nem jellemző.

    Hát nem. Lásd html, xaml. Pont hogy nem vizuálisan írod le, hanem szépen kóddal mint a 70-es, 80-as években. Az utolsó ahol még vizuálisan írtad le, a windows.forms volt, illetve régebben a Delphi és a VB.

    Ugyanez vonatkozik a grafikus fejlesztésre is. Az UML alapú CASE rendszerek visszaszorulóban, Pl. a netbeansból is kikopott az UML designer, és a Visual Studió-ban is csak az ultimate-ben van ha jól tudom, lejjebb max. class diagramot rajzolgathatsz ha akarsz. Az Entity Framework-ben is a code first a first class citizen, sőt mintha hallottam volna olyat is, hogy hosszú távon a designer meg is fog szűnni.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Köszönöm mindenkinek a választ.

    Az MVVM-nek utána fogok nézni. Valahogy én is úgy gondoltam, hogy a WPF a befutóbb, mert itt legalább a XAML kódot meg lehet nézegetni akár egy Jegyzettömbben, a WinForms esetén ez nekem anno nem tűnt ilyen "egyszerűnek" .

    klorand, a DBA munkán én is gondolkodtam, csak ilyenben egy évig sem (sőt semeddig sem) dolgoztam, és eddig mindig olyan lehetőségeket láttam, ahol több éves gyakorlatot kívánnak meg. Ráadásul valahogy legtöbbször elvárás a Linux, én nekem a Windows meg a képernyőolvasó miatt jobban fekszik. Persze ez MsSQL Servernél nem lenne gond. És őszintén szólva a tudásom sincs meg jelenleg ehhez a feladathoz. De lehet, hogy hosszabb távon, ha a fejlesztői munka nem jönne be, ebbe az irányba fogok elmozdulni , mert alapvetően mindig is szerettem az adatbázisokat, SQL lekérdezéseket, tárolt eljárásokat írni, stb.


    É
    Mutasd a teljes hozzászólást!
  • WPF (ill. egyéb XAML felületek esetén) más az ajánlott programozási minta. Ezeknél pont az az egyik legfontosabb szempont, hogy elválasszák az UI-t a kódtól, azaz a designer munkáját a kódolástól, így adatkötéssel, pl. MVVM minta segítségével, eseménykezelők közvetlen használata nélkül célszerű ilyen alkalmazásokat készíteni (legalábbis jobb helyeken).

    Igazából semmi nem akadályozza meg a fejlesztőt, hogy WPF "codebhind" felület kódjába írja a logikát is, mint ahogy azt sem, hogy a winforms-nál szétválassza a kettőt, ami már több, mint 25 éve létező pattern egyébként, csak mostanság kezdenek rájönni igazán, hogy mennyire fontos a rendszer szép felépítése, tesztelhetősége hosszútávon, legalábbis jobb helyeken. Van, ahol szépen WPF-eznek rétegesen, de közben meg egy excel táblázatban vezetik a több 100 manuális teszt esetet és pipálgatják "futtatáskor", szóval semmi nem garantál semmit.
    Mutasd a teljes hozzászólást!
  • Kerdezo, DBA munkan nem gondolkodtal mar? Nekem ugy tunik, hogy ott nagyobb hangsuly van konzolos potyogesen es bizonyos szinten jobban megfizetik, mint az atlag .net-es alkalmazasfejlesztest. Nincs sok ralatasom e teruletre, csak egy otlet, hatha segit.
    Mutasd a teljes hozzászólást!
  • Az a baj, hogy amit LC is ír kis és közepes cégeknél ahogy esik úgy puffan fejlesztés megy, viszont ezek a cégek azok, ahova viszonylag könnyű elhelyezkedni és ezek hajtanak a pályázatokra, csökkent munkaképességű emberek utáni támogatásokra is. Jelmondat: "Ne a megélhetés motiváljon, hanem az izgalmas feladatok" és itt izgalom alatt azt kell érteni, hogy amit tegnap eladtak, azt holnapra be kell fejezni, de már holnap után teljesen más a cél megint és persze mindenkinek fotómemóriája van, dokumentáció az nincs.

    Multinál lehet olyan, hogy szépen szét van választva minden, valami agilis módszerrel dolgoznak napról-napra segítve egymást és esetleg még TDD-t is használnak, meg mindenre van külön ember. Új projektet winforms-al nem nagyon szoktak elkezdeni, itt általában valami ősi rendszert kell ganajozni. Nekem speciel nem jön be az, hogy vizuális tartalmat is kóddal kell leírni, sőt manapság inkább ennek fordítottja a trend, vagyis a logika kódját is vizuálisan írják le, de üzleti alkalmazásoknál ez annyira nem jellemző.
    Mutasd a teljes hozzászólást!
  • Én még annyit tennék hozzá, hogy láthatóan egy kalap alá veszed a WPF/Forms alkalmazásokat, holott nagyon nem ugyanúgy kell ezeket elkészíteni.

    XAML esetén (Forms-zal ellentétben) pont nem az a jellemző, hogy pixelre pontosan egérrel húzogatja az ember a control-okat, ott is inkább kódolás-jellegű munkát kell végezni (a különböző méretű kijelzőre elrendeződés miatt), de tény, hogy nem árt látni a végeredményt.

    az automatikusan generált kódban ugyebár ott vannak az eseménykezelők

    WPF (ill. egyéb XAML felületek esetén) más az ajánlott programozási minta. Ezeknél pont az az egyik legfontosabb szempont, hogy elválasszák az UI-t a kódtól, azaz a designer munkáját a kódolástól, így adatkötéssel, pl. MVVM minta segítségével, eseménykezelők közvetlen használata nélkül célszerű ilyen alkalmazásokat készíteni (legalábbis jobb helyeken).

    Tehát én úgy látom, hogy normális cégnél elvileg semmi akadálya, hogy backend-den dolgozz, ha abban egyébként jó vagy (multik simán foglalkoztatnak megváltozott munkaképességű embereket), viszont úgy látom, célszerű jobban belemélyedni a XAML (WPF, UWP appok stb.) világába, mert attól még, hogy az UI-t egy erre szakosodott kolléga készíti, együtt kell tudni működni vele.

    Részemről is respect: elképzelni is nehéz, hogy hogyan tudsz ennyi információt fejben tartani, vizuális segédeszköz nélkül.
    Mutasd a teljes hozzászólást!
  • Szia,

    A winforms ahogy én az eddigi projekteket láttam nagyjából ahogy esik úgy puffan. Láttam már többrétegű alkalmazást is (én is így csináltam a saját projektemben anno), láttam olyat is ahol a dataset fenn volt a formon és benne voltak az SQL utasítások. A WPF-nél viszont nagyon kutyaütőnek kell ahhoz lenni, hogy ne több rétegű legyen a progi.
    Mutasd a teljes hozzászólást!
  • Hát annyit tudok mondani, hogy nálunk (egy meglehetősen eléggé nagy ügyviteli rendszer) elég szigorúan tartjuk az n-tier felépítést, mert így ugyanaz a kód (egészen a ViewModel szintig) szolgálhatja ki a Windowsos WPF kódot, a Xamarin.Forms-os iOS, Android, WP-s mobil appokat és a Xamarin.Mac-ben írt maces desktop klienst is. A webes kliens fejlesztés alatt áll, de ha jól tudom, az Edge.js is ugyanezeket a ViewModeleket használja és pakolásszuk ki webre. (Hogy miért nem asp.net-et használunk; azt én se tudom, engem a mobilos részért terhel a felelősség )

    Multiplatformra dolgozó cégeknél szerintem eléggé elterjedt kell, hogy legyen, hiszen a kevés plusz munka bőven megtérül azzal, hogy ha valami új fícsört építünk be, vagy hibát javítunk, akkor az egyszerre hat platformon jelenik meg.


    Ja és minden elismerésem, hogy látássérültként programozol!
    Mutasd a teljes hozzászólást!
  • Szia hurka!

    Köszönöm válaszod. Ez megnyugtató. Hmmm... Azért a DataSetek a designer kódban, ez egy kicsit nagyon kompakt megoldás . A másik jobban tetszik . Köszi még egyszer.
    Mutasd a teljes hozzászólást!
  • Szia,

    Szerintem normális körülmények az n-tier felépítés lenne az elvárt, de arról nem tudok nyilatkozni, hogy mennyire jellemző. Dolgoztam olyan projekten, ahol a winforms designer nézetbe rángatták be a dataseteket is (azok tartalmazták az sql lekérdezéseket is).
    De dolgoztam olyan projekten is, ahol az üzleti logika, adatelérés egy WCF service-en keresztül volt elérhető. Mind a klienst (WPF), mind a service-t  ugyanaz a csapat csinálta.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Nagy szükségem lenne a segítségetekre.
    Látássérültként (vak vagyok) képernyőolvasó szoftverrel használom a Visual Studiot. .NET programozóként szeretnék állást találni. Ezidáig ASP.NET MVC frameworkkel volt munkatapasztalatom. Az egér használata vakon nem igazán megoldható hatékonyan, de ez az MVC-nél nem annyira gond, itt számomra gondot csak a kliens réteg vizuálisdesignja jelenthet, de a többi réteg (üzleti logika, adatelérés), azaz acontroller és a model nem jelent semmilyen akadályt.
    Ami a gondom, hogy sok munkáltatónál szükséges WPF vagy Win Forms alkalmazások fejlesztése. A formok kialakítása az egér használata nélkül igen lassú. Bár a XAML kódot akár a jegyzettömbben is szerkeszthetem, mégis fejben kiszámolni, hogy melyik kontrollt pixelre pontosan hova tegyem ki, elég vesződséges. Nem lenne ugye szerencsés, ha pl. a kontrollok egymást részben/egészben takarnák, stb.
    A kérdésem az lenne, hogy az n-tier felépítés jellemezheti-e a WPF/Win Forms alkalmazásokat, vagy ezt csak kifejezetten webalkalmazásokra használjuk? Nagyobb projekteknél jellemző-e, hogy mondjuk az üzleti logika, vagy az adatelérés külön komponensekben kerül kifejlesztésre? Ebben az esetben nagyban nőnének az esélyeim, hogy ilyen alkalmazás fejlesztésében is részt tudjak venni, mert pl. az adatelérés esetén LINQqueryk megírása semmilyen gondot nem jelent, vagy bármely más kódolási feladat sem, ahol nem a GUI-t kell tervezni.
    Én olyanra is gondoltam, hogy ha valaki kolléga elkészítené a GUI-t, és az automatikusan generált kódban ugyebár ott vannak az eseménykezelők, innen már tovább fejleszteni nem okozna gondot. A funkcionális tesztelés során a képernyőolvasó már együtt tud működni a WPF/Win Forms alkalmazással, csak az ergonómikus, designos form készítés ütközik nehézségekbe.
    Bármilyen gondolatot, segítséget, megjegyzést várok e témában. Tudom, ez kicsit speciális helyzet, így, ha valami részemről még tisztázásra szorul, kérdezzetek!

    Előre is köszönöm!
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd