MVC pattern – desktopra és webre (a'la dr. House :-) )
Jött egy (szokás szerint) "zseniális" ötletem: szeretném ugyanazt az applikációt párhuzamosan webre és desktopra is elkészíteni.
Valahol elveszthettem a fonalat az MVC tanulmányozásában, mert eredetileg úgy gondoltam, a modell és a kontroller nagyjából azonos lehetne, csak a view az, amit cserélni kell mögötte.
De minél tovább gondolkodom rajta, annál inkább oda lyukadok ki, hogy egyedül a modell, ami közös lehet, ezt akár 1:1-ben fel tudom használni, a view egy része is megírható úgy, hogy csak a megjelenítő eszközt cserélgetem (mondjuk elkészít egy XML-t, amiből aztán ha web, akkor a böngésző állítja elő a HTML-t XSLT segítségével, ha meg desktop pl. gtk-ra vagy qt-re alapozott megjelenítéssel, akkor megírom a szükséges kódot, ami az XML-ben kapott adatokat az adott rendszeren megjeleníti).
De a kontroller?
Jól érzem, hogy itt még annyira sem lehet újrahasznosítani a webre írt kódot desktopon/desktopra írt kontrollert weben, amennyire a view esetében?
Weben mondjuk az URL... khm... előre elnézést, ha marhaságot írok, szóval az URL routing lenne a fő feladata. Desktopon ilyesmi nem jellemző, ott leginkább a GUI-t kezelő rendszer üzeneteinek a feldolgozása lenne a feladata, ami viszont teljes mértékben eltér a webes technológiáktól. (nincs URL, nincs session kezelés stb.)
---------------
dr. House csak úgy jön ide, hogy végeredményben "hangosan" gondolkodom, hátha valaki hozzászólásától beindul az agyam maradéka. :-)
■ Valahol elveszthettem a fonalat az MVC tanulmányozásában, mert eredetileg úgy gondoltam, a modell és a kontroller nagyjából azonos lehetne, csak a view az, amit cserélni kell mögötte.
De minél tovább gondolkodom rajta, annál inkább oda lyukadok ki, hogy egyedül a modell, ami közös lehet, ezt akár 1:1-ben fel tudom használni, a view egy része is megírható úgy, hogy csak a megjelenítő eszközt cserélgetem (mondjuk elkészít egy XML-t, amiből aztán ha web, akkor a böngésző állítja elő a HTML-t XSLT segítségével, ha meg desktop pl. gtk-ra vagy qt-re alapozott megjelenítéssel, akkor megírom a szükséges kódot, ami az XML-ben kapott adatokat az adott rendszeren megjeleníti).
De a kontroller?
Jól érzem, hogy itt még annyira sem lehet újrahasznosítani a webre írt kódot desktopon/desktopra írt kontrollert weben, amennyire a view esetében?
Weben mondjuk az URL... khm... előre elnézést, ha marhaságot írok, szóval az URL routing lenne a fő feladata. Desktopon ilyesmi nem jellemző, ott leginkább a GUI-t kezelő rendszer üzeneteinek a feldolgozása lenne a feladata, ami viszont teljes mértékben eltér a webes technológiáktól. (nincs URL, nincs session kezelés stb.)
---------------
dr. House csak úgy jön ide, hogy végeredményben "hangosan" gondolkodom, hátha valaki hozzászólásától beindul az agyam maradéka. :-)
Pokki
Jelenleg azt mondanám hogy várd meg mi lesz az MS win8 as HTML5 appjaiból, ha meg most azonnal kell, akkor pokki: https://developers.pokki.com/
Köszi
Egyrészt azt hittem, egyértelmű: eszembe sem jutott, hogy egyedi ötlet, csak eddig nem foglalkoztam a témával.
Másrészt inkább az elméleti rész érdekel a téma, nem a gyakorlati kivitelezés lehetősége.
(de ha már gyakorlat: pl. django vs python+gtk vagy színtiszta java stb.)
Ez a pokki is érdekes, de nekem úgy tűnik, nem egészen arra való, amin gondolkodtam...
API
Ott szerintem elvész az
Nem?
Szóval csak a szokásos: nem a megoldás a problémás (legalábbis elméletben), hanem egy adott elv/környezet/stb. felhasználásával előállítani mindezt.
Arról nem beszélve, hogy ehhez a változathoz akkor is kellene a web(? feltéve, hogy maradok a http mellett, mert ilyen alapon inkább valami MQ jellegű dologra gondolnék) szolgáltatás, ha egyszerű desktop applikációként használnám.
A model egy az egyben
Ha mondjuk ilyesmit csinálnék, akkor silverlight-ban tenném, mert ott elég egyszer megírni. Vagy minimum egy kész keretrendszert használnék fel, ami képes ilyesmire... Ha belegondolsz, a model-en kívül az egész csak transzformáció. Először megtudod a kérésből, hogy melyik controller fogja lekezelni, szóval pl az url-t transzformálod controllerré, utána megadod a controller-nek a kéréssel kapcsolatos adatokat, az meg transzformálja őket a model-nek megfelelő formára, pl egy objektum hálóra. Utána a model már tudja kezelni őket. A view megkapja a model-től a kimenő adatokat, és ő szintén transzformálja őket pl html-re.
Asszem, jogos: routingot csak
Silverlight? Nem mostanában lőtte le a MS?
De
Desktop alkalmazást miért készítesz egyébként, ha meglesz a böngészőben is?
Nem készítek, csak jár az
Mivel érdemi munkára nem tudok koncentrálni, marad, hogy ilyen hülyeségeken gondolkodom. :-)
Újra végiggondolva...
Ugyanis a gyakorlatban, ha webre akarok fejleszteni, akkor szinte biztos, hogy valamilyen webes keretrendszert fogok használni (kivétel PHP).
Ha ezt teszem, akkor már a modellt sem tudom 1:1-ben átvenni a desktopra - feltéve, hogy használom a keretrendszer ilyen jellegű szolgáltatásait (Djangoból kiindulva)
Szóval ez egy hamvába hótt ötlet volt.
(hogy miért pont a Tiszta kód, egységtesztelésről szóló részének olvasása közben jutott ez eszembe... :-) )
Ugyanis a gyakorlatban, ha
Most két külön dologról beszélsz. Egy dolog eleve úgy elindulni a projekttel, hogy webre és asztalra is kell, egy másik meg elindulni vele webre, aztán megpróbálni tákolni valamit asztalra. Egyébként mindkettő megoldható, csak a második kicsit nehezebb, ha már kénytelen vagy egy erre a célra nem feltétlenül alkalmas keretrendszert használni...
Igen, ezzel tisztában vagyok.
Jó, itt megint közrejátszik az én szűklátókörűségem: pythonban nagyon nem szeretnék keretrendszer nélkül, egyszerűen CGI-t használva dolgozni egy webes programon.
Ahogy a javaban írt alkalmazást sem tudok elképzelni mondjuk egy tomcat v. hasonló környezettől mentesen.
Egyebet meg nem ismerek.
Biztos, hogy megvan a
Az Adobe AIR -ről hallottál már?
NuSphere PhpDock
Az egész program annyit tud, hogy egyben tartalmaz egy webszervert és egy böngészőablakot mindenféle böngészős sallangok nélkül és lokális módban frankón futtatja a webalkalmazásodat. SqLite adatbázissal a háttérben még mysql-t sem kell telepíteni hozzá.
Kutya vacsorája
Egy eset a kivétel (amit én tudok): a talán ma már elavultnak számító, számomra Delphi-ben megismert kliens-szerver programozás. Egy szerveroldali és egy kliensoldali progit írsz, ezek pl. TCP/IP-n látják egymást, a kliens kezeli a felhasználói üzeneteket (eseményeket), a szerver tárolja / szolgáltatja az adatokat. A klienst Júzernek telepítenie (és beállítania) kell, nem kell hozzá böngésző, stb. Előnye, hogy kevés adatforgalommal "megy", kb. ugyanúgy műxik (felhasználói szemmel), mint egy sima desktopapp., hátránya, hogy minden kliensnek kell lennie internetkapcsijának. Az feladattól függ, hogy előny v. hátrány, de egy adatbázisod van egy helyen mindenki számára. (Azért kizárva nincsenek a helyi táblák sem.) Hátrány még, hogy ebből nem tudom hogy lehet (lehet-e) épkézláb html in/outputot csinálni (,de szerintem ebben az esetben nem is kell).