ASP.NET WebForms o MVC?
È da molto tempo che rifletto su questo post, ed ho deciso di parlarne solo ora in quanto la seconda release di ASPNET MVC è prossima al rilascio (al momento in Release Candidate, vedi qui): di riflesso, se ne comincia a parlare molto di più e, ancor più interessante, si comincia ad utilizzarla molto di più.
Sinceramente sono rimasto scioccato da quanto interesse e “strada facile” abbia riscontrato ASP.NET MVC rispetto al papà ASP.NET Web Forms. Di fatto noto come alcuni providers italiani, a non molto tempo dal rilascio della prima release di MVC, offrano già disponibile il nuovo Framework, mentre in passato per avere una versione aggiornata del Framework .NET si doveva aspettare parecchio dopo il suo rilascio. Segno che qualcosa stia veramente cambiando?
Parlando con più persone durante speech, conf, chat, etc ho avuto l’impressione che molti reputino ASP.NET MVC la manna dal cielo e le webforms il MALE.
Sinceramente sono rimasto basito dalla cosa, in quanto reputo MVC un’alternativa alle Web Forms e non un concorrente.
Durante la sessione di Bologna ho cercato di esprimere questo concetto e di portare come esempio gli scenari in cui un Framework può avere vantaggi rispetto all’altro, proprio a dimostrazione che non sono concorrenti.
IMHO la riuscita di un buon prodotto non dipende soltanto dalla qualità tecnica del prodotto, ma anche da come si è riusciti a sfruttare le risorse a propria disposizione (e per risorse intendo tutto,team, budget, tempistiche, etc).
Sicuramente tra le cose da non sottovalutare quando si debba effettuare una scelta importante, come lo è l’utilizzo delle Webforms a discapito di MVC, sono i numerosi vantaggi che le prime possono offrire ripetto al secondo in determinati scenari e/o requirements.
In primis la pluritestata e diffusissima tecnologia che, nonostante ciò che si dica, riesce ad essere altamente scalabile ed estendibile e, da non trascurare, l’approccio Windows form style.
Proprio su questo approccio volevo portare un esempio nato durante lo speech di Bologna, in cui in un team misto (Applicazioni Windows e Applicazioni Web) si aveva la necessità di ricollocare alcune risorse sullo sviluppo web. Per chi viene dal mondo delle Windows Forms ASP.NET MVC risulta sicuramente scomodo e/o complesso; al contrario con le webforms il passaggio è quasi indolore e, in questi scenari, le WebForms possono essere la scelta che decide la riuscita di un progetto.
Personalmente (salvo imposizioni particolari), non realizzerei mai un BackOffice (tipicamente contraddistinto da una buona percentuale di dataentry) in ASP.NET MVC, salvo che uno dei requirements sia la testabilità.
Ovviamente MVC non offre soltanto il vantaggio della testabilità, ma anche la possibilità di avere il controllo totale del markup (ASP.NET 4.0 si avvicina molto a questo) ed una forte espandibilità maturata dall’esperienza fatta precedentemente con ASP.NET WebForms.
Per concludere, le webforms non sono morte, anzi vivono ed in molti scenari vivono alla grande ;)
The comments for this post are closed.
- There is no TrackBack for this post.
#1 da Andrea Saltarello Monday January 2010 alle 11:01
ma tanto è sempre il solito discorso: se si raccolgono i requisiti (ergo, si fa analisi), poi le scelte architetturali/tecnologiche vengon da sè, e non dipendono certo dai "gusti" personali.
Ma tant'è: sembra che "pensare" prima di "fare" sia uno sport ormai fuori moda :-)
P.S.: se usate correttamente, le web forms sono testabili *tanto quanto* MVC
#2 da Marco Parenzan Monday January 2010 alle 11:49
Mi permetto di fare le mie considerazioni, da neo utente MVC e MAI utente WebForm:
- una ditta che lavora su siti Web si trova meglio su MVC che su WebForm
- collegato al punto precedente, entrando nella mentalità di jQuery e css si lavora molto meglio con MVC
- ASP.NET WebForm non è stata l'evoluzione di ASP 3.0, ma un nuovo approccio diverso per portare, come dici, gli utenti da VB6.0 al Web
- MVC è, a mio avviso, l'evoluzione di ASP 3.0
- io però, da utente Windows Forms, non mi sono mai trovato con le WebForms, perchè mi sono creato una aspettativa sul designer che ad un certo punto bisognava saltare...
- concordo con quanto detto da Andrea: si può scrivere codice WebForm testabile, basta applicare i pattern giusti
- se l'applicabilità di WebForm a applicazioni è misurata con l'esistenza di controlli e "maturità", bon va bene...
- però, ad esempio, io mi sono scritto una partialView calendario e un paginatore veramente con poco sforzo, e di designer erano molto contenti per i css.
- credo che RenderAction di MVC2 (non l'ho ancora provato, è in MVC2 o in Futures?) sia una gran cosa, spece per un Content Management con le Partial View, molto più leggero ed efficace di UserControl
Riassunto: credo che MVC sia una figata. Personalmente non mi sono mai trovato con WebForms.
Ciao,
Marco Parenzan
#3 da Marco Parenzan Monday January 2010 alle 11:57
Volevo dire ancora una cosa, forse una bestemmia.
Io sono un piccolo sviluppatore, e il testing non me lo paga nessuno, per me ha veramente poco valore. Ribadisco che è una bestemmia, me ne rendo conto, ma per me rientra nelle condizioni reali piuttosto che in quelle teoriche.
Per me è invece molto importante l'applicazione di pattern come Repository o IoC.
I punti di estensione, come ControllerFactory e ViewEngine, ModelBinder siano una gran bella cosa...e semplice da usare.
Adesso sono incuriosito poi da Spark, soprattutto quanto l'integrazione con Visual Studio sarà pronta.
Ciao di nuovo.
Marco Parenzan
#4 da Ugo Lattanzi Monday January 2010 alle 03:24
Ciao Marco,
>credo che MVC sia una figata. Personalmente non mi sono mai trovato con WebForms.
Io ritengo che MVC sia FIGO (ci ho fatto un blogengine :D). Cmq ritengo che le webforms non siano il male. Ti assicuro che tutti i ragazzi che lavorano con me, una volta visto MVC, si sono messe le mani sui capelli a dover gestire action, post e non avere eventi al click etc.
Che tu non abbia avuto problemi nel passaggio da windows form a MVC è sicuramente vero e ci sta tutta come cosa, ma ho visto (e continuo a vedere) persone che da windows form utilizzano le webforms, senza particolari problemi, cosa che non accade con MVC.
Molti dev non sa neanche cosa sia la IoC (e mangari neanche gli interessa), idem la testabilità (neanche a me l'hanno pagata mai :D) e a queste persone (ce ne sono molte) vagli a spiegare che MVC te le offre e che è una roba figa.
Il mio concetto è, la scelta di un framework o un'altro va ponderata anche in base alle risorse (e lo skill di queste) e non solo da quanto sia figa una tecnologia rispetto all'altra.
Probabilmente ha ragione Andrea nel dire che una corretta analisi (che include anche lo skill del team) ti porta alla giusta scelta.
Riguardo a Spark vieni alla mia sessione alla Ugi Alt Conference :P
Ciauz
#5 da raffaeu Saturday January 2010 alle 03:38
Urca che bella discussione.
Dico la mia. Abbiamo il CRM fatto tutto in ASP.NET e va benone. Ha IRepository, usa Nhb, TDD e vatte la pesca.
Il CTO, grande persona, ha letto il libro su MVC e adesso vuole che io e il web dev lo risviluppiamo in MVC. Il primo enorme problema che ho riscontrato é la completa mancanza di controlli nella UI ... e su una applicazione LOB Web non potete parlarmi di JQuery e CSS perché a mio parere la manuntenibilità del prodotto va a farsi benedire. E poi quanti sviluppatori web conoscono cosi' bene JQuery? E questo é solo uno dei punti a sfavore di MVC.
Ok la validazione e il pattern nativo MVC sono FIGHI ma io mica mi baso su quello per sviluppare, altrimenti farei tutto su WPF e WCF ... ma la realtà é ben diversa.
Come sempre il mitico Andrea ha ragione. Analisi, design e requisiti prima di lanciarsi nelle mode del momento. Basta vedere i cambiamenti mastodontici da MVC 1 a 2 e da EF 3 a EF 4 ...
#6 da Marco Parenzan Monday January 2010 alle 01:51
Raffaele,
sto affrontando i Dynamic Languages (Python, in particolare) e la loro immediatezza, quando cominci ad entrare in "temperatura" (scrivere codice), è notevole. Stessa cosa per Javascript.
L'insieme di Duck Typing, Prototyping, Ajax e jQuery è veramente un portento.
Non lo so quanti sviluppatori web conoscono così bene jQuery, ma è un passaggio doveroso così come è stato necessario imparare i CSS.
Comunque non si tratta di "figo" o "non figo". Se parli di "analisi" e "design", MVC rientra tra i pattern applicabili, non modaioli.
Permettimi. Se posso oramai faccio tutto in WCF e WPF: il binding di WPF, per esempio, a me sta dando un rapporto 1:10 con il codice WinForm.
Non ho ancora fatto il passaggio a MVC2. Non mi pare che sia una rivoluzione.
Una domanda: come consideri Ajax? E come consideri il supporto Ajax in WebForm? A me sembra un accrocchio....
Che EF4 sia una "rivoluzione" rispetto a EF1 può darsi, ma vuoi mettere la rivoluzione dell'EF1/Linq2SQL da Dataset?
Se la realtà è ben diversa (come dici tu), l'immediatezza di EF1 (a scapito delle funzionalità) è assai più attraente per esempio di NHibernate (più potente, certo, ma non drag&drop come EF). Io onestamente non sento la mancanza del Lazy Loading.
Per chiudere....il mio passaggio a MVC non è modaiolo. Io non ho mai sviluppato Web e ora ho cominciato proprio perchè è arrivato MVC.
Credo sia un errore considerare MVC modaiolo. Probabilmente è un errore (che sto facendo anche io, sia chiaro) considerare candidato alla morte WebForms. Solo il tempo dirà quale sarà la verità.
Per me è solo un gran bel momento questo!
Ciao,
Marco
#7 da Marco Parenzan Monday January 2010 alle 02:00
Raffaele,
un'aggiunta (a parte scusarmi della formattazione del post precedente....ma sai....l'ora tarda....e mi sto pure inc......do con le WebForms! :)
Sabato ho assistito alla sessione di Ugo su Spark View Engine. Non è modaiola la sensazione che Spark diventerà il ViewEngine di default di MVC, a parte il fatto che LuisDeJardin è diventato dipendente Microsoft. Al primo sito MVC che ho consegnato, i designer hanno detto due cose:
1. bello per il controllo totale dell'HTML e riduzione al minimo del codice C# (al minimo l'entità)
2. rottura di scatole (cinesi) dei code blocks annidati.
Magari avrà bisogno di una formalizzazione (definizione di un namespace, ad esempio), ma Spark a sensazione è la strada giusta.
Ho visto NVelocity, ma non mi è piaciuto...a pelle...
Non sarà una risposta professionale, ma la sensazione è quella....
Ciao,
Marco