Az ASP.NET WebForms, hogy kicsit szabadosan fogalmazzak szívás!
Tegyük fel hogy szeretném a világ legjobb Webes alkalmazását létrehozni .NET környezetben, ami:
- könnyen kiterjeszthető
- könnyen módosítható
- a felhasználói számára könnyen kezelhető
- könnyen testre szabható
- nem utolsó sorban megfelel a mai kor technikai és felhasználói elvárásainak
Én azt állítom, hogy az ASP.NET WebForms erre nem alkalmas eszköz.
A ViewState, a Postback, a Modulok (Pluginok) összehangolt kezelése csak nagy nehézségek árán érhető el vele.
A gond a WebForms-sal hogy nem erre tervezték, bármennyire is igyekszik az ember szépíteni, nem lehet vele olyan moduláris webalkalmazást felépíteni ami megfelel a következő kritériumoknak:
- Zárt Alkalmazás API,
- Független Modulok
- Dinamikusan Betöltött Modulok (Plugin)
- Központi Futtatási környezet
Zárt Alkalmazás API:
A legfontosabb megoldandó probléma az üzleti logika definiálása, a modulok interfészeinek definiálása.
Ez ideáig stimmel, sehol sincs ASP.NET a képben.
Független Modulok:
Kezd kissé problémássá válni a helyzet, de nem megoldhatatlan...
Elsőként mi is a modul, mit várunk el tőle?
A Modul olyan alkalmazás rész ami a Core.API-ra épülve annak erőforrásait felhasználva valami hasznos dologgal egészíti ki az alkalmazást.
No de, ha ASP-NET-ről beszélünk akkor elengedhetetlen hogy a kiegészítés mind Üzleti Logika mind pedig Felhasználó felületen megoldható legyen.
Ehhez vegyük hozzá az ASP.NET WebForms felépítését
(gyk: Control Fa -> ViewState -> Postback)
Hogy egy Nyomógombot helyezzünk el a Modul egyik űrlapján biztosítani kell hogy Postback esetében az adott Control a Postback feldolgozásakor is példányosítva legyen.
(Tehát pl. nem lehet a Modul control-t ASP.NET Cache-elt controlba beágyazni, csak akkor ha a beágyazáskor figyelembe vesszük a postback követelményeket is... Ugyanígy kell eljárni akkor is ha N mélységben ágyazunk be Controlokat egy Cache-elt Controlba)
Ha az adott Controlt dinamikusan hoztuk létre egy
Másik Control értékére alapozva, a vonatkozott control inicializálása, és felépítése meg kell hogy előzze az adott Modul control felépítését.
Ez utóbbi a ViewState feladata. Mondhatnánk, hogy meg van a megoldás, de sajnos nem teljesen igaz:
Az ASP.NET control inicializálás, kiértékelés több mint nagy figyelmet igényel a Modul felhasználói felületének megtervezésekor.
Elméletben a Modul független. Modulon belül hegesztéssel megoldható a korrekt inicializálás, de a később kifejtett futtatási környezet erről semmit se tud.
Dinamikusan Betöltött Modul - Plugin:
Az adott modul ideális esetben teljesen független minden más modultól, és kizárólag az API-ra épül.
Egy adott modult ideális esetben az API-ra alapozva mások / máskor is létrehozhatnak.
Ezeket a modulokat amit nevezzünk plugin-nak Reflection-nel be lehet tölteni, feltéve hogy a modulok definíciója az API-ban megtörtént.
Így a Runtime az adott interfészeken keresztül tud kommunikálni a Plugin-nal.
De,
mivel ASP.NET-ről van szó biztosítani kell a felhasználói felületet.
Hogyan lehet elérni:
Definiáljunk a Modul ős Controljait a Core.API-ban és rendereljük adott Controlt az ősön keresztül amikor szükséges.
Hogy a kép árnyaltabb legyen, az ASP.NET compiler bizonyos esetekben eléggé szűkszavú tud lenni ami a hibaüzeneteket illeti.
Központi futtatási környezet:
Kell egy webalkalmazás ami az egész rendszer számára biztosítja a példányosítást minden esetben.
(Vizuális felületnél az oldallekérés és postback, üzleti logika esetében pedig az adott szolgáltatások hostolása)
Ezt végezze el mind az API, mind pedig a Modulok / Pluginok esetében
Biztosítsa a lehetőséget hogy a felhasználói felületet dinamikusan építsük fel (CMS)
És a legfontosabb, stabilan valamint skálázhatóan működjön.
Hogy mi is a probléma a fenti rendszerrel?
Működőképesség: megoldható
Átláthatóság: az üzleti logika mindenképpen átlátható, DE
ott van az a fránya ASP.NET WebForms
a Control-jainak az életcikusával, a ViewState-tel és a Postback-kel
Az ASP.NET oldala sajnos mindennek nevezhető csak átláthatónak nem.
Mert az adott modulok Felhasználói felületének működése
- Függ attól hogy hogyan vannak beágyazva a szölő control-okban.
- Függ attól hogy hogyan építettük fel a controlt a postbacket megelőzően.
- Függ a Control ViewState-től (ami nem ér semmit ha nem építettük újra a control fát a posback feldolgozása közben).
- Nem utolsó sorban függ a szülő Control postback/viewstate feldolgozási állapotától.
Emberi erőforrás igény: legyen egy csapat aki képes időben megoldani, illetve ledokumentálni a fentebb említett rendszert.
Hogy mi lehet a megoldás?!
Az üzleti logika eléréséhez
Rest WCF szolgáltatások a postback "szolgáltatások" helyett...
vagy
Soap WCF szolgáltatások a postback "szolgáltatások" helyett...
Bővebben itt
MSDN - WCF
A felhasználói felület definiálására
ASP.NET MVC a WebForms helyett...
vagy
Castle Monorail (Spark View enginnel) a WebForms helyett...
Bővebben itt
ASP.NET MVC
Castle Monorail és
Spark View Engine
vagy...
???
Ez egy nem egyszerű kérdés,
Véleményem szerint aki ezt most megoldja azé lesz a jövő generációs web programozása Windows .NET környezetben...
Akármi is lesz a megoldás időtálló megoldás kell!
Az elfogadhatatlan hogy az ember épp mire befejezte a "Nagy" projektet lehet is kezdeni az újraírást mert épp egy újabb technológia jön be és az MS. szépen csendben megszünteti a régebbi technológia támogatását... (épp ahogy történt az asmx webszervízzel napjainkban
MSDN WebService (asmx))
Addig is "gyönyörködjük" az ASP.NET webforms lassú kínhalálában...
Happy Coding
