tutorial programacion net mvc lenguaje entre diferencias definicion asp asp.net asp.net-mvc

programacion - php vs asp.net 2018



La mayor ventaja de usar ASP.Net MVC vs formularios web (19)

¿Cuáles son algunas de las ventajas de usar una sobre la otra?

  1. AJAX adecuado, por ejemplo, JSONResults no tiene ninguna tontería de devolución de página parcial.
  2. sin viewstate +1
  3. No hay cambio de nombre de los ID HTML.
  4. Limpiar HTML = sin hincharse y tener una oportunidad decente en la representación de páginas compatibles con XHTML o estándares.
  5. No más de AXD javascript generado.

ASP.NET Web Forms y MVC son dos marcos web desarrollados por Microsoft; ambas son buenas opciones. Ninguno de los marcos web debe ser reemplazado por el otro ni existen planes para que se "fusionen" en un solo marco. El soporte y el desarrollo continuos son hechos en paralelo por Microsoft y ninguno de ellos ''se va''.

Cada uno de estos marcos web ofrece ventajas / desventajas, algunas de las cuales deben tenerse en cuenta al desarrollar una aplicación web. Una aplicación web puede desarrollarse utilizando cualquiera de las dos tecnologías: puede hacer que el desarrollo de una aplicación en particular sea más fácil seleccionando una tecnología frente a la otra y viceversa.

Formularios web ASP.NET:

  • El desarrollo es compatible con el estado • Da la ilusión de que una aplicación web es consciente de lo que el usuario ha estado haciendo, de forma 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 disputado por parte de la comunidad de MVC, pero empujado 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 tiene menos de una curva de aprendizaje para desarrolladores menos experimentados.
  • Caja de herramientas de control más grande • ASP.NET Web Forms ofrece una caja de herramientas mucho más grande y sólida (controles web), mientras que MVC ofrece un conjunto de control más primitivo que depende más de los controles ricos 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; necesita considerar sus kits de 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 hace que sea más fácil (con suerte) para una aplicación web escalar 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 ricas) • Más que nunca, las aplicaciones web son cada vez más ricas como las aplicaciones que se ven en sus escritorios. Con MVC, le brinda la capacidad de integrarse con tales juegos de herramientas (como jQuery) con mayor facilidad y más sin problemas que en formularios Web.
  • Optimización de motores de búsqueda (SEO) amigable / sin estado • Las URL son más amigables para los motores de búsqueda (es decir, mywebapplication.com/users/ 1 - recuperar usuario con una ID de 1 frente a mywebapplication / users / getuser.aspx (identificación pasada en 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 desarrolladores que necesitan un alto grado de control • Muchos controles en formularios web ASP.NET generan automáticamente gran parte del código HTML sin formato que se ve cuando se procesa una página. Esto puede causar dolores de cabeza a los desarrolladores. Con MVC, se presta mejor para tener un control completo con lo que se representa 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 a considerar seriamente.
  • Desarrollo controlado por prueba (TDD) • Con MVC, puede crear pruebas más fácilmente 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.

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 ViewState, No BS. Ciclo de vida de la página ... Solo código eficiente puro.

Cualquiera que tenga la edad suficiente para recordar el 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 era un problema para descubrir qué demonios estaba haciendo. Podría estar equivocado, y espero hacerlo, pero MVC parece regresar a esos viejos tiempos malos.

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

Ahora, alguien con 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ás programando correctamente si tienes demasiado código dentro de tu vista" es como decir "si escribiste 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, me gustarí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 corregirlos?

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 las etiquetas de apertura y cierre, es decir, <% y%> en ASP, pero ahora la única indicación será el símbolo @.

Podría ser el momento de pasar a PHP y esperar otros 10 años para que alguien vuelva a separar el código del contenido.

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

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

Yo personalmente uso formularios web ya que principalmente desarrollamos aplicaciones B2B / LOB. Pero siempre lo hacemos con un patrón de MVP con el que podemos lograr una cobertura de código de 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.

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

) No creo que este nivel de prueba sea tan fácil de lograr en MVC, sin contaminar mi modelo.

El problema con MVC es que incluso para los "expertos" se 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 que esté 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 para las empresas.

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

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

A continuación está la separación forzosa de la preocupación. ¡Pero no te 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 de las cosas que las personas mencionan 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 (código aspx + detrás)

Francis Shanahan,

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

  2. Estoy de acuerdo con su punto con respecto al viewstate. 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 se cambian los nombres de los controles del servidor HTML en el modelo de formulario web ASP.NET y no en los controles html puros. Sea lo que sea, ¿por qué estás tan preocupado si el cambio de nombre se hace? Sé que quieres lidiar con muchos eventos de JavaScript en el lado del cliente, pero si diseñas inteligentemente tus páginas web, definitivamente puedes obtener todas las identificaciones que quieras

  4. Incluso los formularios web ASP.NET cumplen con los estándares XHTML y no veo ninguna hinchazón. Esta no es una justificación de por qué necesitamos un patrón MVC

  5. Una vez más, ¿por qué te molesta con AXD Javascript? ¿Por qué te duele? Esta no es una justificación válida de nuevo

Hasta el momento, soy un fan de desarrollar aplicaciones que usan formularios clásicos ASP.NET Web. Por ejemplo: si desea vincular una lista desplegable o una vista en 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 sobre el dolor que es.

El mayor inconveniente de MVC es que volvemos a los días de ASP. ¿Recuerdas el código de spaghetti de mezclar código de servidor y HTML? Oh, Dios mío, intenta leer una página MVC aspx mezclada con javascript, HTML, JQuery, CSS, etiquetas de servidor y otras cosas ... ¿Algún cuerpo puede responder a esta pregunta?

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

Las principales ventajas de ASP.net MVC son:

  1. Permite el control total sobre el HTML renderizado.

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

  3. Permite el desarrollo controlado por prueba (TDD) .

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

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

  6. URLs RESTful que permiten SEO.

  7. Sin eventos ViewState y PostBack

La principal ventaja de ASP.net Web Form es:

  1. Proporciona desarrollo RAD

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

Los controles javascript modernos, así como las solicitudes JSON se pueden manejar de forma mucho más fácil usando MVC. Allí podemos usar muchos otros mecanismos para publicar datos de una acción a otra. Es por eso que preferimos MVC sobre formularios web. También podemos construir páginas de poco peso.

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

MVC te permite tener más de un formulario en una página, ¡una pequeña característica que conozco pero que 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 vuelva a visitar después de unos meses.

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

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 controla 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 partes de la página. -MVC es divertido de escribir: - opinión personal ;-)

No he visto CUALQUIER ventaja en MVC sobre ASP.Net. Hace 10 años, Microsoft creó 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 aquel entonces y fue una verdadera pesadilla.

No te limites a subirte al tren en aras de la exageración. Todas las ventajas enumeradas anteriormente ya están disponibles en Asp.Net (con más ajustes [ Nuevas características en Asp.Net 4 ] en Asp.Net 4).

Si su equipo de desarrollo o las familias de un desarrollador único con Asp.Net simplemente se adhieren a él y elaboran hermosos productos rápidamente para satisfacer a sus clientes (que pagan sus horas de trabajo). MVC consumirá tu valioso tiempo y producirá los mismos resultados que Asp.Net :-)

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

Las pruebas para sitios pequeños no son un problema, como tampoco lo son las ventajas del diseño cuando un sitio está codificado correctamente, el MVC en muchos sentidos 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 más grandes de múltiples desarrolladores.

Si está trabajando con otros desarrolladores, como PHP o JSP (y adivino los rieles), le resultará mucho más fácil convertir o colaborar en páginas porque no tendrá todas esas "desagradables" ASP.NET eventos y controles en todas partes.

Ya no se siente mal por el uso de "controles que no sean posteriores a la devolución", y piensa en cómo incluirlos en un entorno asp.net tradicional.

Esto significa que los controles de javascript modernos (de uso libre) tales como this o this o todo pueden usarse sin que eso intente ajustarse a una clavija redonda en una sensación de agujero cuadrado.