¿Planea mudarse de ASP.Net Web Forms a ASP.Net MVC?

Question

Si es así, ¿cuándo? ¿y cuánto tiempo cree que tomará el proceso para migrar sus proyectos actuales (si es el caso)?

Answer 1

Lo he estado usando desde hace unos meses. Me encanta MVC. La conversión de proyectos existentes puede no ser realista, dependiendo del tiempo disponible. Tal como lo veo, Web Forms simula el desarrollo de formularios de Windows para la multitud de VB anterior. Si bien MVC no & # 8217; t pretende que sea algo que no es y # 8217; s y sigue el proceso Http más de cerca.

Algunos problemas que veo en MVC

1) Se puede probar con pruebas unitarias

2) Control directo sobre HTML. Hacemos sitios web, ¿cómo aceptamos no poder controlar todo nuestro html?

3) Sin equipaje en el estado de la vista

4) No hay ningún árbol de control para perder el tiempo procesado

5) Enlace automático de un modal desde una publicación de formulario

6) Puede ser bastante sexy

Y algunas desventajas

1) No hay más controles web (y se pierden muchos controles ricos de terceros)

2) Más lento de desarrollar en

3) Gran curva de aprendizaje

4) Todavía en Beta (CTP pronto aunque)

Answer 2

ASP.NET MVC no está destinado a reemplazar los formularios de Web . Son tecnologías diferentes y están diseñadas para diferentes propósitos.

Hacer una declaración general de que diré que solo usaré uno y no el otro es un enfoque de mente muy estrecha, ya que se pierden los pros y los contras de cada tecnología.

Microsoft está comprometido con ambas tecnologías en el futuro y hay muchas características nuevas que vienen en WebForms 4.0.

Estaré utilizando WebForms y ASP.NET MVC, pero observando las necesidades del proyecto actual para tomar la decisión correcta para la implementación actual

Answer 3

Sí para mis nuevos proyectos. Pero no para el software de producción actual.

Answer 4

Sí, de la manera más ordenada posible.

MVC abre .NET al mundo de las Mejores Prácticas para el desarrollo Agile. Trata específicamente las inquietudes sobre la separación de preocupaciones y el acoplamiento / cohesión. También nos permite escribir software más portátil sin crear una dependencia de referencias o componentes específicos del proveedor.

Indudablemente, es un sucesor de WebForms , junto con WPF, independientemente de las relaciones públicas que puedas leer.

La entrada de Wikipedia es bastante clara, incluso antes de ser actualizada para el MVC de Microsoft.

Answer 5

Suponiendo que usted prefiera ASP.NET MVC a Web Forms, vale la pena para un sistema que está en desarrollo / mantenimiento activo.

Pueden coexistir de lado a lado, por lo que es posible migrar partes de la aplicación (nuevas o seleccionadas) y ver cómo funciona. Si es un éxito, sigue adelante.

Un " todo o nada " Sin embargo, la migración puede ser desastrosa: invertir mucho sin una retroalimentación rápida es un gran riesgo.

Answer 6

  

Los formularios web son para IU ricas

Esto se puede hacer de la misma manera con MVC o Webforms. Dentro de un año, llegarán los ricos juegos de herramientas basados ??en MVC (técnicamente ya están aquí si te gustan YUI, ExtJS, etc.) y hacen que este argumento sea nulo e inválido.

  

migra tus proyectos actuales

La migración de un proyecto de WebForms existente a MVC no tiene mucho sentido. ¿Qué vas a ganar? Sin embargo, usar MVC para un nuevo proyecto puede tener mucho sentido dependiendo de sus requisitos.

Answer 7

Para empezar, nunca me gustaron mucho los WebForms, así que comenzar a trabajar con MVC fue como un soplo de aire fresco para mí. Siempre he preferido la separación de las preocupaciones, ya que podía trabajar en los trozos que era realmente bueno para desarrollar, la lógica y el acceso a los datos, y dejar el trabajo de presentación a los miembros del equipo que tenían esa habilidad natural. Creo que la biblioteca MVC facilita que los equipos trabajen juntos en páginas individuales, ya que una persona puede trabajar en el controlador y la otra persona puede trabajar en la vista.

Dicho todo esto, cuando estoy trabajando en proyectos en los que no necesito centrarme tanto en la codificación y está más orientado a la visualización, todavía vuelvo a los formularios web, ya que son mucho más fáciles de implementar. y levantarse y correr. Ambos tienen sus lugares y no creo que uno supere al otro.

Answer 8

Llevo varios meses usando ASP.NET MVC y lo prefiero a los formularios web. Sin embargo, no me veo migrando mis proyectos existentes a MVC. Para mí, sería bastante inútil. Sin embargo, todos mis nuevos proyectos ASP.NET se desarrollarán (o deberían ser) utilizando MVC, ya que es un marco mucho mejor (y más flexible).

Answer 9

Personalmente restringí ASP.NET MVC para sitios web ligeros de Front Office.

Pero aún usa ASP.NET WebForms para aplicaciones Righ BackOffice para aprovechar los ricos controles personalizados y algunas otras características interesantes de Web Forms.

Answer 10

Otra ventaja de mvc es que javascript como jquery es mucho más fácil de implementar, por lo que si planeas usar muchos js, mvc podría ser el camino a seguir.

Answer 11

No, no hay razón para hacerlo. Es un estilo alternativo, uno que no me gusta. Pero esa es solo mi opinión; a mucha gente le gusta y espero que les funcione bien.

Answer 12

Como ya se dijo, no se excluyen mutuamente, y juego para hacer un buen uso de ambos.

IMO MVC es mejor para los sitios web , mientras que los formularios web son mejores para las aplicaciones web .

Por ejemplo, este sitio es un escaparate perfecto donde ASP.NET MVC es una buena opción debido a la naturaleza del sitio y lo que se necesita lograr; otros buenos ejemplos serían una tienda web, un sitio de gestión de proyectos (como Basecamp) o una red social.

Sin embargo, si estuviera desarrollando un sistema corporativo de CRM / ERP, me quedaría con WebForms para obtener controles ricos y más " similar a un escritorio " Modelo de programación, ya que una aplicación de CRM es tradicionalmente el dominio de una aplicación de escritorio.

Answer 13

ASP.NET MVC se adapta mejor a mi estilo de desarrollo deseado, pero desconfío de confiar en él mientras no sea RTM. También es lo suficientemente diferente como para que nuestro código heredado no funcione con él. Si hubiéramos estado practicando el desarrollo impulsado por el dominio, las cosas podrían haber sido más fáciles, pero ...