tutorial - ¿Debo construir mi próxima aplicación web en ASP.NET MVC?

razor mvc (7)

Mi equipo está considerando construir nuestra próxima aplicación web utilizando el marco ASP.NET MVC. Estoy un poco indeciso, como algunos otros, porque todavía está en beta. Realmente quiero sumergirme porque parece ser una excelente manera de proporcionar una clara separación de preocupaciones y mejorar la capacidad de prueba.

¿Debo darme el paso ahora, mientras MVC todavía está en beta, o esperar para un candidato de lanzamiento?

De algunas de las respuestas, creo que necesito aclarar mi pregunta un poco. Mi principal preocupación es si ir con un producto que todavía está en beta, no webforms vs. mvc. La preocupación se debe principalmente al temor de que terminemos utilizando alguna funcionalidad en la versión beta que se modifique / desaproveche / no sea compatible en la versión final.

Sin embargo, aprecio la perspectiva en webforms vs. mvc. Simplemente no llega al corazón de mi pregunta.

A menos que su aplicación sea súper simple, es probable que MVC sea lanzado antes de que vaya a la producción. Eso sin embargo importa poco. He estado construyendo en MVC desde Vista previa 2. Cada nueva versión ha contenido cambios de última hora; sin embargo, no han sido muy difíciles de rastrear y corregir. Es muy poco probable que en 1.0 puedas crear una montaña de código que se derrumbe por algunos cambios bruscos. Simplemente presupuesta algunas horas para aplicar cada nueva versión.

Es un árbol de decisión bastante simple, de verdad.

Elija ASP.NET MVC si ...

Cuida profundamente sobre las URL
Cuida mucho tu HTML
Quiere una verdadera separación de preocupaciones
Desea la capacidad de prueba a través de
Desea flexibilidad en los motores de visualización (ASPX, NVelocity, NHaml, etc.)

Elija WebForms si ...

Disfrute de la abstracción de WebForms (ViewState)
No me molesta el modelo de PostBack
Prefiere los componentes que puedes "arrastrar y soltar" en una página

Para mí, la respuesta será 99% ASP.NET MVC, porque creo que es una combinación mucho mejor para la web. Creo que la historia de Ajax es mucho más limpia también, y tengo control completo sobre mis URL y HTML. Además de todo eso, puedo probar mi sitio web (controladores) con bastante facilidad.

Sí, sé que puede lograr URL limpias en WebForms, y puede tener HTML limpio (er) a través de Adaptadores de control, y puede lograr un nivel de comprobabilidad con el patrón de MVP en WebForms, pero estos son caminos fuera de lo común. enfoques. Con ASP.NET MVC, estas cosas son esenciales. Así es como lo haces.

Y no te preocupes por el estado de vista previa / beta. El equipo siempre ha mantenido que no necesita una licencia de activación para implementarlo (a pesar de que ahora ofrecen uno). Es puramente aditivo en el tiempo de ejecución ASP.NET existente.

Es como transmisión automática vs. transmisión manual. Elija uno que lo haga feliz y corra con él.

Hasta ahora, Mvc se ve bien, sin embargo, yo soy el defensor del castillo. He usado el monorriel en muchos sitios de producción y me ha llevado a conocer IoC y AR Cheack out castleproject.org

Prefiero ASP.NET MVC a WebForms, así que elegiría eso, pero necesita trabajar como un equipo donde se encuentran sus habilidades principales y si elegir MVC o no:

Crea un mejor producto
Llevarte al mercado más rápido.

No lo elijas porque es nuevo. WebForms sigue siendo una gran opción, y puede escribir código para WebForms que sea comprobable y tenga una clara separación de preocupaciones.

Recomiendo darle una oportunidad.

Acabamos de lanzar una plataforma de comercio electrónico con MVC ejecutándose en la interfaz, y aunque hay algunos inconvenientes con los que puede tropezar (decir, resolver Url''s con tipos anónimos es actualmente mucho más lento que usar un RouteValueDictionary, fue una sorpresa para mí) , ciertamente parece que fue mucho más fácil construir un sistema manejable en MVC en comparación con nuestras aplicaciones antiguas de WebForms.

Si tiene el lujo de elegir, entonces definitivamente debe tener una mirada más cercana. Los errores que han aparecido mientras trabajamos han sido solucionados con bastante prontitud, y la mayoría de las cosas funcionan bien ahora, y comienzan a sentirse bastante completas.

Pero al final, siempre es un riesgo asumir un producto beta temprano. :)

Si no es una misión crítica y usted y su equipo tienen tiempo para aprenderlo, ¿por qué no?

Si no tiene que poner su aplicación en producción pronto, sí, escríbala en MVC. Aquí, tenemos un equipo trabajando con MVC y planeando ponerlo en producción en enero de 2009.