2010-03-25 20 views
23

Conosco un sacco di persone che apprezzano davvero i miglioramenti apportati da ASP.NET MVC 2 alla prima versione. Ho appena iniziato la migrazione del nostro progetto MVC 1 e finora le aree hanno completamente ripulito il disordine della sottocartella che avevamo nella nostra applicazione su larga scala. Mentre approfondisco tutti i miglioramenti e le modifiche apportate, continuo a pensare a me stesso che sarebbe bello se avessero x in questa versione. Ad esempio, mi piacerebbe che avessero una sorta di integrazione di dipendenze integrata invece di dover utilizzare soluzioni di terze parti.ASP.NET MVC 3 - Quali caratteristiche vuoi vedere?

La mia vera domanda è ora che ASP.NET MVC 2 è in circolazione, quali caratteristiche desiderano/desiderano che il team abbia implementato e sperano che implementeranno per ASP.NET MVC 3?

EDIT

Sembra che l'iniezione di dipendenza è costruito per la prima versione di anteprima di ASP.NET MVC 3! Mi piacciono le funzionalità aggiunte finora. ASP.NET 3 preview one is out!

+0

Questo deve essere CW –

risposta

10

Penso che MVC 3 non sarà troppo drammatico con i suoi miglioramenti, ma più costante e graduale.

Il ASP.NET MVC 3 Roadmap ha un'istantanea di ciò che apparentemente la squadra sta cercando di implementare nella prossima versione e alcuni punti sono molto interessanti.

Penso che i miei preferiti da quella lista sarebbe probabilmente:

  • Più AJAX Helpers: Questo sarà portare il quadro più in linea con il mondo Webforms che ha già e in qualche misura tutti questi aiutanti, agisce come una barriera per alcune persone che prendono la piattaforma.
  • Altro Dipendenza Iniezione roba - per coloro che lo vogliono, questo è grande.:)
  • Il supporto per il caching migliorato è la grande vittoria per me. Avere quello integrato nel framework sarebbe un grande vantaggio e potrebbe comportare dei buoni risparmi sulle prestazioni.
  • Inoltre ValidationAttributes non andrebbe a mancare. Mentre la struttura è ottima per aggiungerli, una buona libreria di quelli comuni, come Email e PropertiesMustMatch e così via.
6

Vorrei davvero che avrebbero aggiungere il seguente:

  1. condizionali Spark-stile e loop utilizzando attributi di tag html.
  2. Aggiornato: proprietà del progetto visibile per attivare la convalida delle viste in fase di compilazione.
  3. Qualcosa per verificare/verificare che i miei percorsi siano corretti.
  4. Soluzione di provider di appartenenza che utilizza int al posto di Guid per l'identificazione e consente di associare i campi del profilo a una tabella personalizzata anziché l'impostazione predefinita generica ma lenta.
  5. aiutanti Lambda-based per evitare le stringhe di magia (attualmente in MvcFutures)
  6. modello T4MVC di generare automaticamente aiutanti fortemente tipizzati
  7. wizard di progetto o modelli per ottenere un modello che è già configurato per CIO e preoccupazioni simili, preferibilmente con una finestra di dialogo di selezione per scegliere quale framework utilizzare per IoC, test delle unità, ecc.
  8. Attributi aggiuntivi (filtri e convalida).

Hmmm, questo è tutto quello che posso pensare in questo momento :)

+0

1. È possibile sostituire il motore di visualizzazione Spark per alcune delle visualizzazioni e verrà eseguito parallelamente alle visualizzazioni del motore di visualizzazione ASP.NET MVC convenzionale. –

+1

2. Se si esegue questa operazione, si rinuncia a un certo grado di flessibilità (la capacità di modificare le viste mentre l'applicazione è ancora in esecuzione). Le tue opinioni sono davvero così complicate da richiedere la convalida in fase di compilazione? –

+1

7. Sarebbe molto bello. –

4

Tooling (modelli T4) per creare Moq oggetti per unit testing sarebbe molto cool. Testare determinati oggetti nel framework è inutilmente complicato e avere la possibilità di codificarne una parte sarebbe molto utile.

+0

+1 da parte mia su questo. –

+0

++ "inutilmente complicato" – redsquare

4

Vorrei:

Tooling

  • Un punto di vista quotazione alternativa utilizzando AJAX esempio utilizzando jqGrid (attuazione di ordinamento, impaginazione, di ricerca)
  • Miglioramenti CRUD Pagine rilevano entità relazioni per le classi Entity Framework, e di utilizzare un altro set di componenti basati in campi di tipo ad esempio proprio come Dynamic Data:)
+1

+1 per migliori strumenti CRUD. –

3

Poiché ASP.net MVC 3 sarà solo .net 4, mi piacerebbe vedere alcune cose intorno ai controller asincroni e tutte le altre nuove funzioni asincrone/multithreading che .net 4 porta.

1

Mi piacerebbe aiutanti che impalcano automaticamente le viste indice. Forse qualcosa come IndexDisplay(), IndexDisplayFor() e IndexDisplayForModel().

2

mi piacerebbe vedere un supporto integrato per cose come IronRuby

+0

+1 per il supporto Rubino :) – ashes999

1

mi piacerebbe di template per le classi compagno generare automaticamente su un determinato modello.

9

Vorrei la rimozione completa di tutte le stringhe magiche.

2

supporto MEF sarebbe bello.

0

più controlli e aiutanti sarebbe davvero bello, soprattutto una griglia (ajax).

+2

odio parola 'controllo', semplicemente mi ricorda roba come ViewState, postback e cose che faccio al lavoro ora :( – Jarek

1

uso anche la semplicità come la maggior parte delle cose senza helper come html-helper i cosa che lo sviluppo in asp.net MVC 3 è un modo migliore per imparare MVC 3 in futuro.

1

Le due cose che mi piacerebbe vedere la maggior parte sono a iniezione diretta di dipendenza nelle viste, filtri, ecc, e (so che questo è apparentemente sulla strada con il motore di visualizzazione Razor) deve essere in grado di testare le mie viste separatamente dalla pipeline ASP.Net (magari includendo la convalida di doctype e/o qualche tipo di compilazione/convalida di JavaScript).

Qui ci sono alcune altre idee:

  • Sarebbe bello essere in grado di confezionare un componente di interfaccia utente (viste, modelli, modelli di vista, etc.) per il riutilizzo su più progetti. Immagino che questo sia attualmente possibile in qualche modo, ma non ne ho abbastanza bisogno per capirlo da solo.
  • L'idea di controllerless actions mi incuriosisce, soprattutto dal punto di vista SRP.
  • Supporto migliore per il pattern Post-Redirect-Get (P/R/G) ... sembra proprio che ci dovrebbe essere un supporto intrinseco per questo schema molto importante.
2

Mi piacerebbe vedere un nuovo modo di gestire il routing, per semplificare i servizi REST dello sviluppatore. Attualmente ho percorsi come questo:

context.MapRoute(null, 
       "api/posts", 
       new { controller = "Post", action = "Get" }, 
       new { httpConstraint = new HttpMethodConstraint("GET") }); 


context.MapRoute(null, 
       "api/posts", 
       new { controller = "Post", action = "Insert" }, 
       new { httpConstraint = new HttpMethodConstraint("POST") }); 


context.MapRoute(null, 
       "api/posts/{id}", 
       new { controller = "Post", action = "Update" }, 
       new { httpConstraint = new HttpMethodConstraint("PUT") }); 


context.MapRoute(null, 
       "api/posts/{id}", 
       new { controller = "Post", action = "Delete" }, 
       new { httpConstraint = new HttpMethodConstraint("DELETE") }); 

a una nuova persona che utilizza ASP.NET MVC, è molto intuitivo per creare oggetti anonimi per gestire il routing. Mi piacerebbe vederlo rivisto per qualcosa di simile (e dato che stiamo usando C# 4.0):

context.MapRoute("api/posts", 
       controller: "Post", 
       action: "Get", 
       httpMethodConstraint: HttpMethodConstraint.GET 
       ); 

context.MapRoute("api/posts", 
       controller: "Post", 
       action: "Insert", 
       httpMethodConstraint: HttpMethodConstraint.POST 
       ); 

context.MapRoute("api/posts/{id}", 
       controller: "Post", 
       action: "Update", 
       httpMethodConstraint: HttpMethodConstraint.PUT 
       ); 

context.MapRoute("api/posts/{id}", 
       controller: "Post", 
       action: "Delete", 
       httpMethodConstraint: HttpMethodConstraint.DELETE 
       ); 

Ciò renderebbe più rilevabile pure.