¿Cuáles son algunas de las ventajas de usar uno sobre el otro?
¿Cuáles son algunas de las ventajas de usar uno sobre el otro?
Respuestas:
Las principales ventajas de ASP.net MVC son:
Habilita el control total sobre el HTML representado.
Proporciona una separación limpia de preocupaciones (SoC).
Habilita el desarrollo impulsado por pruebas (TDD) .
Fácil integración con frameworks de JavaScript.
Siguiendo el diseño de la naturaleza apátrida de la web.
URLs RESTful que permiten SEO.
No hay eventos ViewState y PostBack
Las principales ventajas del formulario web ASP.net son:
Proporciona desarrollo RAD
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:
ASP.NET MVC:
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.
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
¿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
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.
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
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
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:
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.
runat="server"
etiqueta sin formulario cuando todavía quieres usar formularios web, y como no puedes / no debes anidar formularios, creo que es bastante obvio lo que quiso decir :)
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 BLOCKS
mezcla con HTML
...
html hell para los desarrolladores que lo mantienen ...