2010-03-25 26 views
23

Conozco a un grupo de personas que realmente disfrutan de las mejoras que ASP.NET MVC 2 realizó en la primera versión. Acabo de empezar a migrar nuestro proyecto MVC 1 y hasta ahora las áreas han limpiado por completo el lío de la subcarpeta que teníamos en nuestra aplicación a gran escala. A medida que profundizo en todas las mejoras y cambios que se hicieron, sigo pensando para mí que sería bueno si tuvieran x en este lanzamiento. Por ejemplo, me encantaría que tuvieran algún tipo de inyección de dependencia integrada en lugar de tener que usar soluciones de terceros.ASP.NET MVC 3 - ¿Qué características desea ver?

Mi verdadera pregunta es que ASP.NET MVC 2 está en libertad, ¿qué características desea/desea que el equipo haya implementado y espera que se implementen para ASP.NET MVC 3?

EDITAR

Parece que la inyección de dependencia está construido en la primera versión preliminar de ASP.NET MVC 3! Me gustan las características añadidas hasta ahora. ASP.NET 3 preview one is out!

+0

Esto debería ser CW –

Respuesta

10

Creo que MVC 3 no será tan espectacular con sus mejoras, sino más constante y gradual.

El ASP.NET MVC 3 Roadmap tiene una instantánea de lo que el equipo aparentemente está buscando implementar en el próximo lanzamiento y algunos de los puntos son muy interesantes.

Creo que mis favoritos de esa lista, probablemente sería:

  • Más AJAX Ayudantes: Esto traerá el marco más acorde con el mundo formularios web que tiene todos estos ayudantes ya y hasta cierto punto, actúa como una barrera para que algunas personas ocupen la plataforma.
  • Más cosas de Dependency Injection: para aquellos que lo deseen, esto es genial.:)
  • Mejor soporte de almacenamiento en caché es la gran victoria para mí. Tener eso integrado en el marco sería un gran beneficio y podría resultar en un buen ahorro de rendimiento.
  • ValidationAttributes adicionales tampoco fallarían. Si bien las instalaciones son excelentes para agregarlas, una buena biblioteca de las comunes, como Email y PropertiesMustMatch, etc.
6

Me gustaría que añadir lo siguiente:

  1. condicionales de estilo de chispa y bucles utilizando atributos de etiquetas HTML.
  2. Actualizado: propiedad del proyecto visible para alternar la validación en tiempo de compilación de las vistas.
  3. Algo para verificar/validar que mis rutas sean correctas.
  4. Solución de proveedor de membresía que usa int en lugar de Guid para la identificación y permite asignar los campos de perfil a una tabla personalizada en lugar de la predeterminada genérica pero lenta.
  5. ayudantes basados ​​en lambda para evitar cuerdas mágicas (actualmente en MvcFutures)
  6. plantilla T4MVC a generar automáticamente ayudantes inflexible
  7. asistentes de proyectos o plantillas para conseguir una plantilla que ya está configurado para el COI y preocupaciones similares, preferiblemente con un cuadro de diálogo de selección para elegir qué marco utilizar para IoC, pruebas unitarias, etc.
  8. Atributos adicionales (filtros y validación).

Hmmm, eso es todo lo que puedo pensar ahora mismo :)

+0

1. Puede sustituir el motor Spark view por algunas de sus vistas, y se ejecutará lado a lado con las vistas convencionales del motor de vista ASP.NET MVC. –

+1

2. Si hace esto, renuncia a un cierto grado de flexibilidad (la capacidad de cambiar vistas sobre la marcha mientras la aplicación todavía se está ejecutando). ¿Son sus puntos de vista realmente tan complicados que requieren una validación en tiempo de compilación? –

+1

7. Eso sería muy bueno. –

4

de herramientas (plantillas T4) para crear objetos Moq para las pruebas unitarias sería muy fresco. La prueba de ciertos objetos en el marco es innecesariamente complicada, y tener la capacidad de codificar algo de esto sería muy beneficioso.

+0

+1 de mí en esto. –

+0

++ "innecesariamente complicado" – redsquare

4

me gustaría:

Tooling

  • Una vista listado alternativa usando ajax por ejemplo utilizando jqGrid (implementando clasificación, paginación, búsqueda)
  • Mejoras en las páginas CRUD detectan las relaciones de las entidades para las clases de infraestructura de entidad, y para usar otro conjunto de componentes basados ​​en campos tipo p. ej. tal como lo hace dinámico de datos:)
+1

+1 para mejores herramientas CRUD. –

3

Como ASP.net MVC 3 será .NET sólo el 4, me gustaría ver un poco de materia alrededor de controladores asíncronos y todas las demás funciones nuevas asíncrono/multiproceso que .NET 4 trae.

1

Me gustaría que los ayudantes andamen automáticamente las vistas de índice. Tal vez algo así como IndexDisplay(), IndexDisplayFor() y IndexDisplayForModel().

2

Me gustaría ver una función de soporte para cosas como IronRuby

+0

+1 para el soporte de Ruby :) – ashes999

1

me gustaría plantillas a las clases de amigos generar automáticamente en cualquier modelo dado.

9

Me gustaría la eliminación completa de todas las cuerdas mágicas.

2

El soporte de MEF sería bueno.

0

más controles y ayudantes serían realmente agradables, especialmente una cuadrícula (ajax).

+2

Odio la palabra 'control', me recuerda cosas como viewstate, postback y cosas que hago en el trabajo ahora :( – Jarek

1

también uso la característica de simplicidad como la mayoría de las cosas sin ayuda, como html-helper, pero creo que el desarrollo en asp.net MVC 3 es una mejor manera de aprender MVC 3 en el futuro.

1

Las dos cosas que me gustaría ver la mayoría son de inyección directa dependencia de las vistas, filtros, etc., y (sé que esto es supuestamente en camino con el motor Razor view) es poder probar mis vistas de forma aislada de la tubería ASP.Net (tal vez incluyendo la validación de doctype y/o algún tipo de compilación/validación de JavaScript).

Aquí están algunas otras ideas:

  • Sería agradable ser capaz de empaquetar un componente de interfaz de usuario (vistas, plantillas, modelos de vista, etc.) para su reutilización a través de múltiples proyectos. Supongo que esto es actualmente posible de alguna manera, pero simplemente no lo necesito lo suficiente como para resolverlo por mi cuenta.
  • La idea de controllerless actions me intriga, particularmente desde el punto de vista de SRP.
  • Mejor soporte para el patrón Post-Redirect-Get (P/R/G) ... parece que debería haber un soporte intrínseco para este patrón tan importante.
2

Me gustaría ver una nueva forma de manejar el enrutamiento, para que sea más fácil para los servicios REST del desarrollador. Actualmente tengo rutas como esta:

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 nueva persona con ASP.NET MVC, es muy poco intuitivo para crear objetos anónimos para manejar el enrutamiento. Me gustaría ver que revisó a algo como esto (y ya que estamos 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 
       ); 

Esto haría más fácil de encontrar también.