Mayor ventaja de usar ASP.Net MVC frente a formularios web

¿Cuáles son algunas de las ventajas de usar uno sobre el otro?

Las principales ventajas de ASP.net MVC son:

1. Habilita el control total sobre el HTML representado.

2. Proporciona una separación limpia de preocupaciones (SoC).

3. Habilita el desarrollo impulsado por pruebas (TDD) .

4. Fácil integración con frameworks de JavaScript.

5. Siguiendo el diseño de la naturaleza apátrida de la web.

6. URLs RESTful que permiten SEO.

7. No hay eventos ViewState y PostBack

Las principales ventajas del formulario web ASP.net son:

1. Proporciona desarrollo RAD

2. Modelo de desarrollo fácil para desarrolladores que vienen del desarrollo winform.

ASP.NET Web Forms y MVC son dos frameworks web desarrollados por Microsoft, ambos son buenas opciones. Ninguno de los marcos web debe ser reemplazado por el otro ni hay planes para 'fusionarlos' en un solo marco. El soporte y el desarrollo continuos se realizan en paralelo por parte de Microsoft y ninguno de ellos "desaparecerá".

Cada uno de estos marcos web ofrece ventajas / desventajas, algunas de las cuales deben tenerse en cuenta al desarrollar una aplicación web. Se puede desarrollar una aplicación web utilizando cualquiera de las tecnologías; podría facilitar el desarrollo de una aplicación en particular seleccionando una tecnología en comparación con la otra y viceversa.

Formularios web ASP.NET:

• El desarrollo admite el estado • Da la ilusión de que una aplicación web es consciente de lo que el usuario ha estado haciendo, de manera similar a las aplicaciones de Windows. Es decir, hace que la funcionalidad 'asistente' sea un poco más fácil de implementar. Los formularios web hacen un gran trabajo al ocultar gran parte de esa complejidad al desarrollador.
• Desarrollo rápido de aplicaciones (RAD) • La capacidad de simplemente "saltar" y comenzar a entregar formularios web. Esto es discutido por parte de la comunidad MVC, pero impulsado por Microsoft. Al final, se reduce al nivel de experiencia del desarrollador y con lo que se sienten cómodos. El modelo de formularios web probablemente tenga menos curva de aprendizaje para los desarrolladores menos experimentados.
• Caja de herramientas de control más grande • ASP.NET Web Forms ofrece una caja de herramientas mucho mayor y más robusta (controles web), mientras que MVC ofrece un conjunto de control más primitivo que se basa más en controles enriquecidos del lado del cliente a través de jQuery (Javascript).
• Maduro • Ha existido desde 2002 y hay una gran cantidad de información con respecto a preguntas, problemas, etc. Ofrece más control de terceros: debe tener en cuenta sus herramientas existentes.

ASP.NET MVC:

• Separación de preocupaciones (SoC) • Desde un punto de vista técnico, la organización del código dentro de MVC es muy limpia, organizada y granular, lo que facilita (con suerte) que una aplicación web escale en términos de funcionalidad. Promueve un gran diseño desde el punto de vista del desarrollo.
• Integración más fácil con herramientas del lado del cliente (herramientas de interfaz de usuario enriquecidas) • Más que nunca, las aplicaciones web son cada vez más ricas que las aplicaciones que se ven en sus escritorios. Con MVC, le brinda la capacidad de integrarse con dichos kits de herramientas (como jQuery) con mayor facilidad y sin problemas que en Web Forms.
• Optimización del motor de búsqueda (SEO) amigable / sin estado • Las URL son más amigables con los motores de búsqueda (es decir, mywebapplication.com/users/ 1 - recupera al usuario con un ID de 1 vs mywebapplication / users / getuser.aspx (identificación pasada en la sesión)). Del mismo modo, dado que MVC no tiene estado, esto elimina el dolor de cabeza de los usuarios que generan múltiples navegadores web desde la misma ventana (colisiones de sesión). En esa misma línea, MVC se adhiere al protocolo web sin estado en lugar de "luchar" contra él.
• Funciona bien con los desarrolladores que necesitan un alto grado de control • Muchos controles en los formularios web ASP.NET generan automáticamente gran parte del HTML sin formato que se ve cuando se representa una página. Esto puede causar dolores de cabeza a los desarrolladores. Con MVC, se presta mejor para tener un control completo de lo que se procesa y no hay sorpresas. Aún más importante, es que los formularios HTML suelen ser mucho más pequeños que los formularios web, lo que puede equivaler a un aumento del rendimiento, algo que se debe considerar seriamente.
• Desarrollo guiado por pruebas (TDD) • Con MVC, puede crear más fácilmente pruebas para el lado web de las cosas. Una capa adicional de prueba proporcionará otra capa de defensa contra el comportamiento inesperado.

Autenticación, autorización, configuración, compilación e implementación son todas las características que se comparten entre los dos marcos web.

Cualquier persona lo suficientemente mayor como para recordar ASP clásico recordará la pesadilla de abrir una página con código mezclado con html y javascript, incluso la página más pequeña fue un dolor para descubrir qué diablos estaba haciendo. Podría estar equivocado, y espero que lo esté, pero MVC parece volver a esos viejos tiempos.

Cuando apareció ASP.Net, fue aclamado como el salvador, separando el código del contenido y permitiéndonos que los diseñadores web creen el html y los codificadores trabajen en el código subyacente. Si no queríamos usar ViewState, lo desactivamos. Si no quisiéramos usar el código detrás por alguna razón, podríamos colocar nuestro código dentro del html como el ASP clásico. Si no queríamos usar PostBack, redirigíamos a otra página para su procesamiento. Si no queríamos usar controles ASP.Net, usamos controles html estándar. Incluso podríamos interrogar el objeto Response si no quisiéramos usar ASP.Net runat = "server" en nuestros controles.

Ahora alguien en su gran sabiduría (probablemente alguien que nunca programó ASP clásico) ha decidido que es hora de volver a los días de mezclar código con contenido y llamarlo "separación de preocupaciones". Claro, puede crear html más limpio, pero podría hacerlo con ASP clásico. Decir "no está programando correctamente si tiene demasiado código dentro de su vista" es como decir "si escribió código bien estructurado y comentado en ASP clásico, es mucho más limpio y mejor que ASP.NET"

Si quisiera volver a mezclar código con contenido, consideraría desarrollar usando PHP, que tiene un entorno mucho más maduro para ese tipo de desarrollo. Si hay tantos problemas con ASP.NET, ¿por qué no solucionar esos problemas?

Por último, pero no menos importante, el nuevo motor Razor significa que es aún más difícil distinguir entre html y código. Al menos podríamos buscar etiquetas de apertura y cierre, es decir, <% y%> en ASP, pero ahora la única indicación será el símbolo @.

Tal vez sea hora de pasar a PHP y esperar otros 10 años para que alguien separe el código del contenido una vez más.

Si está trabajando con otros desarrolladores, como PHP o JSP (y estoy adivinando rieles), será mucho más fácil convertir o colaborar en páginas porque no tendrá todos esos ASP.NET 'desagradables' eventos y controles en todas partes.

El problema con MVC es que incluso para los "expertos" consume mucho tiempo valioso y requiere mucho esfuerzo. Las empresas están impulsadas por lo básico "Solución rápida que funciona", independientemente de la tecnología detrás de ella. WebForms es una tecnología RAD que ahorra tiempo y dinero. Cualquier cosa que requiera más tiempo no es aceptable por las empresas.

1. AJAX adecuado, por ejemplo, JSONResults no tiene sentido parcial de devolución de página.
2. sin estado de vista +1
3. Sin cambio de nombre de las ID de HTML.
4. HTML limpio = sin hinchazón y tener una oportunidad decente para representar XHTML o páginas compatibles con los estándares.
5. No más JavaScript AXD generado.

La mayor ventaja para mí sería la clara separación entre sus capas de Modelo, Vista y Controlador. Ayuda a promover un buen diseño desde el principio.

No he visto NINGUNA ventaja en MVC sobre ASP.Net. Hace 10 años, a Microsoft se le ocurrió UIP (Proceso de interfaz de usuario) como respuesta a MVC. Fue un fracaso. Hicimos un gran proyecto (4 desarrolladores, 2 diseñadores, 1 probador) con UIP en ese entonces y fue una verdadera pesadilla.

No te subas al carro por el bien de Hype. Todas las ventajas enumeradas anteriormente ya están disponibles en Asp.Net (con más ajustes excelentes [ Nuevas características en Asp.Net 4 ] en Asp.Net 4).

Si su equipo de desarrollo o una sola familia de desarrolladores con Asp.Net simplemente se adhieren a él y hacen productos hermosos rápidamente para satisfacer a sus clientes (que pagan sus horas de trabajo). MVC consumirá su valioso tiempo y producirá los mismos resultados que Asp.Net :-)

Francis Shanahan

1. ¿Por qué llamas una devolución de datos parcial como "sin sentido"? Esta es la característica principal de Ajax y se ha utilizado muy bien en el marco Atlas y en maravillosos controles de terceros como Telerik

2. Estoy de acuerdo con su punto con respecto al estado de la vista. Pero si los desarrolladores tienen cuidado de deshabilitar viewstate, esto puede reducir en gran medida el tamaño del HTML que se representa, por lo que la página se vuelve liviana.

3. Solo los controles del servidor HTML se renombran en el modelo de formulario web ASP.NET y no los controles html puros. Sea lo que sea, ¿por qué estás tan preocupado si se ha cambiado el nombre? Sé que desea lidiar con muchos eventos de JavaScript en el lado del cliente, pero si diseña sus páginas web de manera inteligente, definitivamente puede obtener todas las identificaciones que desee

4. Incluso ASP.NET Web Forms cumple con los estándares XHTML y no veo ninguna hinchazón. Esto no es una justificación de por qué necesitamos un patrón MVC

5. Nuevamente, ¿por qué te molesta el Javascript AXD? ¿Por qué te duele? Esta no es una justificación válida nuevamente

Hasta ahora, soy un fanático del desarrollo de aplicaciones utilizando los formularios web ASP.NET clásicos. Por ejemplo: si desea enlazar una lista desplegable o una vista de cuadrícula, necesita un máximo de 30 minutos y no más de 20 líneas de código (mínimo, por supuesto). Pero en el caso de MVC, hable con los desarrolladores lo doloroso que es.

El mayor inconveniente de MVC es que estamos volviendo a los días de ASP. ¿Recuerdas el código de espagueti de mezclar el código del servidor y el HTML? Dios mío, intenta leer una página aspx MVC mezclada con javascript, HTML, JQuery, CSS, etiquetas de servidor y qué no ... ¿Cualquier persona puede responder a esta pregunta?

Los formularios web también se benefician de una mayor madurez y soporte de proveedores de control externos como Telerik.

En los formularios web, también puede renderizar casi todo el html a mano, excepto algunas etiquetas como viewstate, eventvalidation y similar, que se pueden eliminar con PageAdapters. Nadie lo obliga a usar GridView o algún otro control del lado del servidor que tenga una salida de representación html incorrecta.

¡Diría que la mayor ventaja de MVC es la VELOCIDAD!

Lo siguiente es la separación forzada de la preocupación. ¡Pero no le prohíbe poner toda la lógica BL y DAL dentro de Controller / Action! Es solo la separación de la vista, que también se puede hacer en formularios web (patrón MVP, por ejemplo). Muchas cosas que la gente menciona para mvc se pueden hacer en formularios web, pero con un esfuerzo adicional.
La principal diferencia es que la solicitud llega al controlador, no a la vista, y esas dos capas están separadas, no conectadas a través de una clase parcial como en los formularios web (aspx + código detrás)

Mis 2 centavos:

• Los formularios ASP.net son excelentes para el desarrollo rápido de aplicaciones y para agregar valor comercial rápidamente. Todavía lo uso para la mayoría de las aplicaciones de intranet.
• MVC es ideal para la optimización de motores de búsqueda, ya que controlas la URL y el HTML en mayor medida
• MVC generalmente produce una página mucho más ágil: sin estado de visualización y HTML más limpio = tiempos de carga rápidos
• MVC fácil de almacenar en caché partes de la página. -MVC es divertido de escribir: - opinión personal ;-)

MVC le permite tener más de un formulario en una página. Una pequeña característica que conozco, ¡pero es útil!

También creo que el patrón MVC hace que el código sea más fácil de mantener, especialmente. cuando lo vuelves a visitar después de unos meses.

Controlador MVC:

    [HttpGet]
    public ActionResult DetailList(ImportDetailSearchModel model)
    {
        Data.ImportDataAccess ida = new Data.ImportDataAccess();
        List<Data.ImportDetailData> data = ida.GetImportDetails(model.FileId, model.FailuresOnly);

        return PartialView("ImportSummaryDetailPartial", data);
    }

Vista MVC:

<table class="sortable">
<thead>
    <tr><th>Unique Id</th><th class="left">Error Type</th><th class="left">Field</th><th class="left">Message</th><th class="left">State</th></tr>
</thead>
<tbody>
    @foreach (Data.ImportDetailData detail in Model)
    {
    <tr><th>@detail.UniqueID</th><th class="left">@detail.ErrorType</th><th class="left">@detail.FieldName</th><th class="left">@detail.Message</th><th class="left">@detail.ItemState</th></tr>
    }
</tbody></table>

¿Qué tan difícil es eso? Sin ciclo de vida de ViewState, No BS Page ... Solo código eficiente puro.

Puedo ver que las dos únicas ventajas para sitios más pequeños son: 6) URL RESTful que permiten SEO. 7) No hay eventos ViewState y PostBack (y mayor rendimiento en general)

Las pruebas para sitios pequeños no son un problema, tampoco lo son las ventajas de diseño cuando un sitio está codificado correctamente de todos modos, MVC de muchas maneras se ofusca y hace que los cambios sean más difíciles de realizar. Todavía estoy decidiendo si estas ventajas valen la pena.

Puedo ver claramente la ventaja de MVC en sitios de desarrolladores múltiples más grandes.

El principal beneficio que encuentro es que obliga al proyecto a una estructura más comprobable. Esto también se puede hacer fácilmente con los formularios web (patrón MVP), pero requiere que el desarrollador comprenda esto, muchos no lo hacen.

Webforms y MVC son herramientas viables, ambas se destacan en diferentes áreas.

Yo personalmente uso formularios web, ya que desarrollamos principalmente aplicaciones B2B / LOB. Pero siempre lo hacemos con un patrón MVP con el que podemos lograr una cobertura de código de más del 95% para nuestras pruebas unitarias. Esto también nos permite automatizar las pruebas en las propiedades de los controles web. El valor de la propiedad se expone a través de la vista, por ejemplo

bool IMyView.IsAdminSectionVisible{
       get{return pnlAdmin.Visible;}
       get{pnlAdmin.Visible=value;}
    }

) No creo que este nivel de prueba se logre tan fácilmente en MVC, sin contaminar mi modelo.

Ya no te sientes mal por usar 'controles que no son posteriores a la devolución' y descubrir cómo colocarlos en un entorno asp.net tradicional.

Esto significa que los controles javascript modernos (de uso gratuito) como esto o esto o esto se pueden usar sin tratar de ajustar una clavija redonda en una sensación de agujero cuadrado.

Los controles javascript modernos, así como las solicitudes JSON, pueden manejarse con mucha facilidad usando MVC. Allí podemos usar muchos otros mecanismos para publicar datos de una acción a otra. Es por eso que preferimos MVC sobre los formularios web. También podemos construir páginas livianas.

Mi opinión personal es que, la mayor desventaja de usar ASP.Net MVC es que se CODE BLOCKSmezcla con HTML...
html hell para los desarrolladores que lo mantienen ...