Habemus MVC3 (preview 1)
L’annuncio arriva direttamente dal blog di Scott Guthrie, anche se il download era apparso sui server Microsoft già da alcune ore: sta di fatto che MVC 3 Preview 1 è stato rilasciato, e lo potete scaricare direttamente qui.
Anche la versione 3 sembra percorrere quanto già fatto dalla versione 2, ossia evolvere quanto di già buono c’è senza stravolgere la struttura, quindi non aspettatevi di trovare grandissimi cambiamenti all’interno di questa release.
Tra le novità è stato incluso Razor, un view engine “csharp like” che va ad affiancarsi al view engine già presente, permettendo così di avere View scritte con differenti sintassi; un’altra novità molto interessante è la presenza dell’IServiceLocator, che personalmente ritenevo una mancanza in MVC2 (in dexter abbiamo implementato un qualcosa di simile).
In linea di massima tutta la parte di Dependency Injection è stata migliorata e di fatto ora è possibile andare a “giocare” con controller, viewengine, views, validation providers, model meta data provider, model binder, e chi più ne ha più ne metta.
Sono presenti anche altre novità di minor rilievo come ViewData dinamico, che sfrutta la keyword dynamics di c# 4 e di conseguenza vincola l’utilizzo di MVC3 all’ultima release del .NET Framework.
Direi che di argomenti e spunti per poter parlare e provare MVC3 ce ne sono, e sicuramente un confronto di Razor con Spark non tarderà ad arrivare.
Ciauz
The comments for this post are closed.
- There is no TrackBack for this post.
#1 da RoBYCoNTe Wednesday July 2010 alle 09:50
Ahaha, simpaticissimo notare nei feed che tu e Scott Guthrie siete apparsi nei feed uno sotto l'altro, ormai si può dire che avete la stessa potenza di fuoco!
Comunque semplicemente fantastico! Le features sembrano davvero interessanti e nello stesso tempo non stravolgono nulla!
#2 da Marco Tuesday September 2010 alle 03:18
Avevo letto tempo fa un tuo post relativo alla comparazione tra MVC e WebForm. In tale occasione ti eri espresso a favore delle seconde in quanto a produttività.
Ora che Telerik e altri creatori di componenti iniziano a proporre soluzioni equivalenti anche per il mondo MVC come la vedi?
Nel senso, scegliere di realizzare un backend piuttosto esteso e complesso in MVC è proprio una pazia?
#3 da Ugo Lattanzi Wednesday September 2010 alle 09:53
Ciao Marco,
scusa se ti rispondo solo ora ma è stato (in realtà lo è ancora) un periodaccio.
Devo dire che MVC2 in quanto a produttività ha fatto tantissimi passi in avanti ed in alcuni scenari è molto più produttivo delle webform; Per quanto riguarda MVC3 la preview attuale non include grandissime produttività, quindi per ora rimane più o meno in linea con la version 2.
In risposta alla tua domanda, ad oggi con la 2 di MVC realizzerei molto volentieri un backend piuttosto esteso :)
Tu che ne pensi?
Ciauz
#4 da Marco Wednesday September 2010 alle 11:09
Ciao Ugo
Io provengo dal mondo asp "classico", ho una buona dimestichezza con html, css e javascript.
Malgrado il linguaggio vbscript fosse obsoleto, ero riuscito a raggiungere una elevatissima produttività soprattutto nella creazione dei backend.
Avevo creato dei componenti (semplici classi) per la generazione di tutta la UI. Ovvero non dovevo scrivere nemmeno una riga di HTML.
Tutta la pagina veniva creata mettendo insieme i vari componenti (pagina, griglia, menu, path, form ...)
Se devo essere sincero, ho sempre guardato con diffidenza il pradigma delle webform.
Avevo letto un mezzo manuale della wrox in merito e un programmatore era venuto in anzienda a farci una "demo" della tecnologia webform.
Rimasi scioccato dalla complessità dell'architettura.
Nell'azienda in cui lavoro ora mi si chiede di scegliere la tecnologia con la quale siviluppare un progetto molto esteso (non il classico sitarello ecommerce). I tempi sono come al solito ridotti e la speranza è quella di fare la scelta giusta "al primo colpo".
Mi sono quindi orientato verso Asp MVC (ed ho già ricreato quasi tutti i componenti con qui creare le UI).
Ma non avendo mai provato serimente a sviluppare con WebForm il dubbio mi rimane: ho fatto la scelta giusta?
Sono confortato dalla tua risposta.
Vedendo poi il trend degli ultimi anni mi sembra che si stia puntando sempre di più su UI fortemente interattive e ajax a tutto spiano.
Dimmi se sbaglio, ma la tecnologia del viewstate e del postback alla base di webform mi sembrano quindi destinati a diventare obsoleti.
So che anche con webform è possibile utilizzare ajax ma da quello che ho letto (posso sbagliarmi) non è molto produttivo.
Tecnologie come GWT o TBITS mi sembrano un passo avanti. Secondo me MVC è un passo verso quella meta.
Che ne pensi?
#5 da Ugo Lattanzi Wednesday September 2010 alle 02:04
Ciao Marco,
IMHO hai fatto la scelta corretta, con la versione 2 di MVC si possono raggiungere grandi risultati e ad oggi sono pochi gli scenari in cui WebForms può far pendere l'ago della bilancia dalla sua parte.
Al momento l'unico scenario che vi viene in mente in cui le WebForms possono ancora dire la loro è legato allo skill del team che, se si hanno a disposizione risorse WinForm, sicuramente MVC può risultare ostico.
Per quanto riguarda AJAX, direi che jQuery la fa da padrone e con la pulizia del markup di MVC c'è poco da scegliere :).
Ciauz
#6 da Marco Friday September 2010 alle 12:46
Ciao Ugo
come avevo scritto, sto cercando di creare una interfaccia di amministrazione.
Anche quando sviluppavo con i miei componenti in vbscript c'era sempre il problema di mantenere lo stato dei vari controlli sulla pagina.
La soluzione che avevo trovato era poco elegante e poco flessibile:
1) lo stato dei controlli è ricavabile dall'url
es: prodtti.asp?griglia_ordine="prodott_titolo"&griglia_pagina=5&mostrafiltro=true
2) Limitare al massimo il numero dei controlli. In una pagina il massimo dei controlli che posso avere di cui devo mantenerne lo stato è una griglia e una form per filtrare i dati.
3) Ogni controllo può accedere ai dati dell'url e creare al suo interno pulsanti (link) che richiamano la pagina mantenendo lo stesso url (modificando solo ciò che mi interessa)
Ovvero il pulsante della griglia per andare alla pagina 6 recupererà l'url attuale e modificherà solo il parametro griglia_pagina
prodtti.asp?griglia_ordine="prodott_titolo"&griglia_pagina=5&mostrafiltro=true
Volevo capire se a tuo avviso esiste un sistema migliore. Anche se con ASP MVC non c'è viewstate non significa che non ci sia la necessità di mantenere comunque lo stato dei controlli sulla pagina.
Marco
#7 da RoBYCoNTe Friday September 2010 alle 01:28
Scusate se mi intrometto, ma la discussione si fà interessante, io mi trovo a dover utilizzare ambedue le tecnologie, premettendo che nel caso in cui fosse possibile, con MVC si può comunque utilizzare WebForms, per quanto riguarda quello che tu stai facendo ed il problema dello stato dei controlli, puoi anche sfruttare contenitori come ViewData e TempData, ambedue assomigliano molto al famoso StateBag dei WebForm, in questo caso però, disponibili con MVC in due varianti per sopperire a due problemi. ViewData permette il passaggio di dati tra Controller ed Action mentre TempData permette il passaggio di dati tra diversi Controller (quindi nell'eventualità di avere Action Redirect).
Alla fine il buon senso aiuta molto, sfruttare la Request come fai tu io la ritengo sempre e comunque cosa buona e giusta (delle volte mi sono ritrovato a discutere con gente che usa la Sessione per salvare variabili assurde o interi recordset da scorrere... ma questa... è roba da MANICOMIO!)
Roberto
#8 da Ugo Lattanzi Saturday September 2010 alle 03:50
Ciao Marco e Roberto,
il problema dello stato dei controlli in MVC lo hai sicuramente allo stesso modo di ASP.NET, mentre le webforms, come avete giustamente affermato, vi vengono in aiuto grazie al viewstate.
L'approccio di mettere alcune informazioni nell'url della richiesta non è del tutto sbagliato, ed in alcuni scenari è sicuramente la scelta migliore (proprio riguardo la paginazione da te mansionata, se l'url cambia, l'indicizzazione è migliore, al contrario di quanto accade con il postback delle webforms).
Però è anche vero che non si può mettere tutto nella querystring e magari non è neanche bellissimo che alcune informazioni ci finiscano. Oltre al TempData che ha giustamente nominato Roberto, una soluzione può essere quella di sfruttare i Binder di MVC (http://msdn.microsoft.com/it-IT/library/dd410405.aspx) in modo da ritrovarsi gratis una classe popolata con le informazioni necessarie al ciclo di vita dell'applicazione nel controller che riceverà l’informazione successiva.
Anche se normalmente i Binder vengono associati all’input di informazioni dell’utente, questo non significa che non li si possa sfruttare anche per altri scopi.
Fammi sapere se effettui delle prove e quale tipo di approccio scegli.
Ciauz
#9 da RoBYCoNTe Tuesday September 2010 alle 10:16
Sono d'accordo con te Ugo, la queryString và usata, ma nel modo giusto! Il ModelBinder invece è il massimo! (mi verrebbe da dire Fighissimo!).
OT: Ugo quando invio un messaggio si nota una certa lentezza nel browser (io scrivo e dopo pochi secondi visualizzo il contenuto nella textarea), ho provato da altre parti, il problema non si verifica, qui invece si, volevo solo farti presente questa cosa :)
#10 da Ugo Lattanzi Thursday October 2010 alle 05:07
Ciao Roby,
grazie per la segnalazione, sto lavorando al backoffice in questo periodo. Appena finito questo sprint gli do un'occhiata.
Ma te lo fa con tutti i browser? Te lo chiedo perchè non riesco a riprodurlo :(
Fammi sapere.
Ciauz
#11 da RoBYCoNTe Thursday October 2010 alle 05:41
Ugo sinceramente qui a casa questo problema non lo sto notando per niente, forse può essere la macchina da cui ti scrivevo (in ufficio) il vero problema!