130 votos

¿Alguien a mi lado simplemente no llegar ASP.NET MVC?

He estado jugueteando con ASP.NET MVC desde el CTP, y me gustan muchas de las cosas que hizo, pero hay cosas que simplemente no entiendo.

Por ejemplo, he descargado la beta 1, y estoy armando un pequeño sitio personal/curriculum vitae/blog con ella. Aquí es un fragmento de la ViewSinglePost vista:

 <%
        // Display the "Next and Previous" links
        if (ViewData.Model.PreviousPost != null || ViewData.Model.NextPost != null)
        {
            %> <div> <%

            if (ViewData.Model.PreviousPost != null)
            {
                %> <span style="float: left;"> <%
                    Response.Write(Html.ActionLink("<< " + ViewData.Model.PreviousPost.Subject, "view", new { id = ViewData.Model.PreviousPost.Id }));
                %> </span> <%
            }

            if (ViewData.Model.NextPost != null)
            {
                %> <span style="float: right;"> <%
                    Response.Write(Html.ActionLink(ViewData.Model.NextPost.Subject + " >>", "view", new { id = ViewData.Model.NextPost.Id }));
                %> </span> <%
            }
            %>
                   <div style="clear: both;" />
               </div> <%
        }
    %>

Un asco! (Tenga en cuenta también que el HTML no es marcador de posición temporal HTML, voy a hacer un diseño real una vez que la funcionalidad está trabajando).

Estoy haciendo algo mal? Porque pasé muchos días oscuros en ASP clásico, y esta sopa de etiqueta me recuerda fuertemente de ella.

Todo el mundo predica cómo se puede hacer un limpiador HTML. Adivina, ¿qué? 1% de todas las personas, aspecto en el que salen como HTML. A mí, no me importa si Webforms arruina mi sangría en el renderizado de HTML, siempre que tenga un código que es fácil de mantener...Esto no es!

Por lo tanto, convertir mí, un die hard webforms chico, ¿por qué debo renunciar a mi muy bien formado páginas ASPX para esto?

Edit: en Negrita el "temp Html/css" la línea para que la gente stfu sobre ella.

136voto

Mark Brittingham Puntos 18970

En comparación a los Formularios Web, MVC es a la vez un bajo nivel de enfoque para la generación de código HTML con un mayor control sobre el resultado de la página y de un nivel superior, más de arquitectura-enfoque basado en. Permítanme captura de Formularios Web y MVC y mostrar por qué creo que la comparación favorece a los Formularios Web forms en muchas situaciones - siempre y cuando no caigas en algunos clásicos de Formularios Web forms de trampas.

Los Formularios Web

En el modelo de Formularios Web forms, sus páginas se corresponden directamente con la solicitud de la página desde el navegador. Por lo tanto, si usted está dirigiendo a un usuario a una lista de Libros, es probable que tenga una página en algún lugar llamado "Booklist.aspx" a la que va directo a él. En esa página, usted tendrá que proporcionar todo lo necesario para mostrar la lista. Esto incluye el código para la extracción de datos, la aplicación de cualquiera de lógica de negocio, y mostrar los resultados. Si hay cualquier arquitectura o la lógica de enrutamiento que afectan la página, tendrás el código de la lógica de arquitectura en la página. Buena Web de las Formas de desarrollo por lo general implica el desarrollo de un conjunto de clases de apoyo en un aparte (unidad-comprobable) DLL. Estas clase(s) se encargará de la lógica de negocio, acceso a datos y arquitectura/decisiones de enrutamiento.

MVC

MVC una más de "arquitectura" punto de vista de desarrollo de aplicaciones web: ofreciendo una estandarizada andamio sobre el que construir. También proporciona herramientas para la generación automática de modelo, vista y controlador de clases dentro de la arquitectura. Por ejemplo, tanto en Ruby on Rails (sólo "Rails" de aquí en adelante) y ASP.NET MVC siempre vas a empezar con una estructura de directorio que refleja su modelo general de arquitectura de aplicaciones web. Para agregar una vista, el modelo y el controlador, tendrás que usar un comando como Rieles "Rieles script/generate scaffold {nombre del modelo}" (ASP.NET MVC ofrece comandos similares en el IDE). En la clase de controlador, habrá métodos ("Acciones") para el Índice (mostrar lista), Muestran, de Nuevo, Editar y Destruir (al menos en los Rieles, MVC es similar). Por defecto, estas "Acciones de incluir el Modelo de la ruta y la correspondiente vista/archivo html en la Vista "/{nombre del modelo)" directorio (tenga en cuenta que hay también Crear, Actualizar y Destruir acciones que manejar un "Post" y la ruta para regresar al Índice o Mostrar).

La disposición de los directorios y archivos es significativo en MVC. Por ejemplo, en ASP.NET MVC, el Índice de método para un "Libro objeto" es probable que sólo una línea: "Return View();" a Través de la magia de MVC, esto va a enviar el Libro modelo para el "/Ver/Libros/Index.aspx" de la página en donde encontrará el código para mostrar los Libros. Los rieles del enfoque es similar aunque la lógica es un poco más explícito y menos "mágico". Una Vista de página en una aplicación MVC es generalmente más simple que el de una página de Formularios Web forms, porque no tienen que preocuparse acerca de enrutamiento, la lógica de negocio o la gestión de datos.

Comparación

Las ventajas de MVC giran en torno a la separación de preocupaciones y un limpiador, HTML/CSS/AJAX/Javascript centrado en el modelo para la producción de su salida. Esto mejora la capacidad de prueba, ofrece un diseño estandarizado y abre la puerta a una más "Web 2.0", el tipo de sitio web.

Sin embargo, hay algunas desventajas significativas así.

En primer lugar, aunque es fácil conseguir un sitio de demostración, el general de arquitectura modelo tiene una curva de aprendizaje significativa. Cuando dicen "Convención Sobre Configuración" suena bien - hasta que te das cuenta de que tienes un libro-la pena de convenio para aprender. Además, a menudo es un poco desesperante para averiguar lo que está pasando porque están confiando en la magia, en lugar de llamadas explícitas. Por ejemplo, que "Volver la Vista();" la llamada anterior? Exactamente la misma llamada se puede encontrar en otras Acciones, pero que ir a diferentes lugares. Si usted entiende el MVC convención , a continuación, usted sabe por qué se hace esto. Sin embargo, ciertamente no se puede considerar como un ejemplo de buen nombre o fácilmente comprensible y es mucho más difícil para los nuevos desarrolladores para recoger de Formularios Web (de esto no se acaba de opinión: había un pasante de verano de aprender de Formularios Web el año pasado y MVC este año y las diferencias en la productividad se pronuncia en favor de los Formularios Web). Por CIERTO, Rails es un poco mejor en este aspecto a pesar de Ruby on Rails características dinámicamente el nombre de métodos que toman algunos graves obtención de-utilizar-a así.

Segundo, MVC implícitamente asume que usted está construyendo un clásico CRUD de estilo del sitio web. Las decisiones arquitectónicas y, especialmente, los generadores de código son todos construidos para apoyar este tipo de aplicación web. Si usted está construyendo una aplicación CRUD y quiero adoptar una probada de la arquitectura (o simplemente disgusta el diseño de la arquitectura), entonces usted probablemente debería considerar la posibilidad de MVC. Sin embargo, si usted va a estar haciendo más de IMPUREZAS y/o que razonablemente competente con la arquitectura, a continuación, MVC se puede sentir como una camisa de fuerza hasta que realmente dominar el subyacente modelo de enrutamiento (que es considerablemente más complejo que simplemente enrutamiento en una de Formularios web app). Incluso entonces, me he sentido como yo siempre estaba luchando contra el modelo y preocupado por los resultados inesperados.

Tercero, si no te importa para Linq (ya sea porque tienen miedo de que Linq-to-SQL que va a desaparecer, o porque usted encontrar Linq to Entidades graciosamente sobre-producido y bajo powered), a continuación, usted también no desea transitar este camino desde ASP.NET MVC herramientas de andamiaje que se construya alrededor de Linq (este fue el asesino para mí). Los rieles del modelo de datos es también bastante torpe en comparación con lo que se puede lograr si se tiene experiencia en SQL (y especialmente si usted está bien versado en TSQL y procedimientos almacenados!).

Cuarto, MVC proponentes señalan con frecuencia que vistas de MVC están más cerca en espíritu a los de HTML/CSS/AJAX modelo de la web. Por ejemplo, "HTML Helpers" - el pequeño código de llamadas en su vew página de intercambio de contenido y el lugar en los controles HTML - son mucho más fáciles de integrar con Javascript de controles de Formularios Web forms. Sin embargo, ASP.NET 4.0 introduce la capacidad de nombre de los controles y por lo tanto en gran medida elimina esta ventaja.

Quinto, MVC puristas a menudo se burlan de Viewstate. En algunos casos, el derecho de hacerlo. Sin embargo, Viewstate también puede ser una gran herramienta y una gran ayuda a la productividad. A modo de comparación, el manejo de Viewstate es mucho más fácil que intentar integrar web de terceros a los controles en una aplicación MVC. Mientras que el control de la integración puede ser más fácil para MVC, todos los esfuerzos que he visto sufrir a partir de la necesidad de construir (un poco grody) código de enlace de estos controles a la vista del Controlador de la clase (que es - para evitar el modelo MVC).

Conclusiones

Me gusta MVC desarrollo de muchas maneras (aunque yo prefiero los Rieles para ASP.NET MVC por un tiro largo). Yo también creo que es importante no caer en la trampa de pensar que ASP.NET MVC es un "anti-modelo" de ASP.NET los Formularios Web. Son distintas pero no completamente ajena y sin duda, hay espacio para ambos.

Sin embargo, yo prefiero Web de Formas de desarrollo porque, para la mayoría de las tareas, es simplemente más fácil de hacer las cosas (con la excepción de la generación de un conjunto de CRUD formas). MVC también parece sufrir, en cierta medida, de un exceso de teoría. De hecho, ver a las muchas preguntas hechas aquí por la gente que sabe orientado a la página ASP.NET pero que están tratando de MVC. Sin excepción, no es mucho crujir de dientes como a los desarrolladores a encontrar que ellos no pueden hacer tareas básicas sin necesidad de saltar a través de aros o soportar una enorme curva de aprendizaje. Esto es lo que hace que los Formularios Web superior para MVC en mi libro: MVC te hace pagar un mundo real de precios con el fin de obtener un poco más de capacidad de prueba o, peor aún, a ser simplemente genial , ya que está utilizando la última tecnología.

Actualización: he sido criticado fuertemente en la sección de comentarios - algunos de ellos bastante justo. Por lo tanto, me han pasado varios meses de aprendizaje de los Rieles y ASP.NET MVC sólo para asegurarme de que no estaba realmente perdiendo la próxima gran cosa! Por supuesto, también ayuda a garantizar que me proporcionan una equilibrada y adecuada respuesta a la pregunta. Usted debe saber que la respuesta anterior es una reescritura importante de mi respuesta inicial en caso de que los comentarios parecen fuera de sincronización.

Mientras yo estaba mirando más de cerca en MVC pensé, por un poco de tiempo, que iba a terminar con un gran mea culpa. Al final llegué a la conclusión de que, mientras que yo pienso que nosotros tenemos que gastar mucha más energía en la Web Formas de la arquitectura y de la capacidad de prueba, MVC, en realidad, no responder a la llamada para mí. Así, un caluroso "gracias" a la gente que siempre inteligente críticas de mi respuesta inicial.

Para aquellos que vieron esto como una religiosa de la batalla y que implacablemente ingeniería downvote inundaciones, no entiendo por qué te molesta (20+ abajo-votos en cuestión de segundos el uno del otro en varias ocasiones, no es ciertamente normal). Si usted está leyendo esta respuesta y se pregunta si hay algo verdaderamente "equivocada" sobre mi respuesta, dado que el resultado es mucho menor que algunas de las otras respuestas, el resto aseguró que se dice más acerca de un par de personas que no están de acuerdo que el sentido general de la comunidad (en general, este ha sido upvoted más de 100 veces).

El hecho es que muchos desarrolladores no se preocupan por MVC y, de hecho, este no es un punto de vista minoritario (incluso dentro de MS como de los blogs parecen indicar).

117voto

Hugoware Puntos 13645

MVC le da más control sobre su salida, y con ese control tiene un mayor riesgo de escribir mal diseñadas en HTML, las etiquetas de la sopa, etc...

Pero, al mismo tiempo, usted tiene varias opciones nuevas que no tenía antes de...

  1. Más control sobre la página y los elementos dentro de la página
  2. Menos "basura" en su salida, como el ViewState o excesivamente largo Identificadores de elementos (no me malinterpreten, me gusta el ViewState)
  3. Mejor capacidad para hacer el lado del cliente programación con Javascript (Aplicaciones de la Web 2.0 a nadie?)
  4. No sólo MVC, pero JsonResult es slick...

Ahora eso no quiere decir que usted no puede hacer ninguna de estas cosas con WebForms, pero MVC hace más fácil.

Yo todavía uso de Formularios web para cuando tengo que crear rápidamente una aplicación web desde la que puedo tomar ventaja de los controles de servidor, etc. WebForms oculta todos los detalles de la entrada de las etiquetas y los botones de envío.

Ambos WebForms y MVC son capaces de absoluta basura si usted es descuidado. Como siempre, la planificación cuidadosa y bien pensado diseño, el resultado será una aplicación de calidad, independientemente de si está MVC o WebForms.

[Actualización]

Si es que alguna consolación así, MVC es sólo una nueva, la evolución de la tecnología de Microsoft. Ha habido muchos mensajes que WebForms no sólo permanecen, sino que continúan siendo desarrollado para...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... y así sucesivamente...

Para aquellos preocupados por la ruta MVC está tomando, yo sugiero que dar a "los chicos" tus comentarios. Ellos parecen estar escuchando hasta ahora!

73voto

J Wynia Puntos 4679

La mayoría de las objeciones a ASP.NET MVC parece centrada alrededor de las vistas, que son uno de los más "opcional" y modular los bits en la arquitectura. NVelocity, NHaml, Chispa, XSLT y otros motores de vista puede ser fácilmente intercambiado (y ha sido más fácil con cada versión). Muchos de los que tienen MUCHO más concisa de la sintaxis para hacer la lógica de presentación y formato, a la vez que completa el control sobre la emisión del HTML.

Más allá de eso, casi todos los de la crítica se parece a venir a la <% %> marcado en las vistas predeterminadas y lo "feo" que es. Que opinión a menudo está arraigada en el ser utilizado para la WebForms enfoque, que sólo se mueve la mayoría de la ASP clásico fealdad en el archivo de código subyacente.

Incluso sin hacer código-detrás de "malo", tienen cosas como OnItemDataBound en los Repetidores, que es tan estéticamente feo, si sólo de una manera diferente, de "sopa de etiqueta". Un contenedor de bucles foreach puede ser mucho más fácil de leer, incluso con la variable de integración en la salida de ese bucle, especialmente si usted viene a MVC de otros non-ASP.NET tecnologías. Se tarda mucho menos Google-fu para entender el bucle foreach que averiguar a que la forma de modificar un campo en el repetidor es meterse con OnItemDataBound (y la rata del nido de comprobar si el elemento adecuado para ser cambiado.

El mayor problema con la etiqueta ASP-sopa-driven "spaghetti" era más para empujar cosas como la base de datos de las conexiones entre el código HTML.

Que le pasó a hacerlo con <% %> es sólo una correlación con los espaguetis a la naturaleza de ASP clásico, no de la causalidad. Si usted mantiene su opinión de que la lógica de HTML/CSS/Javascript y el mínimo de lógica necesaria para hacer la presentación, el resto es la sintaxis.

Cuando se comparan dado un poco de funcionalidad a WebForms, asegúrese de incluir todos los de el generado por el diseñador de C#, y el código de C#, junto con la .aspx código para asegurarse de que el MVC solución es realmente no es, de hecho, mucho más simple.

Cuando se combina con el uso juicioso de vistas parciales para repetible bits de la lógica de presentación, que puede ser realmente agradable y elegante.

Personalmente, le deseo mucha de la década del contenido del tutorial se centró más en este fin de cosas que casi exclusivamente en el test-driven, de la inversión de control, etc. Mientras que otras cosas es lo que los expertos objeto, los chicos en las trincheras son más propensos a oponerse a la "sopa de etiqueta".

Independientemente, esta es una plataforma que aún está en beta. A pesar de eso, es el CAMINO más despliegue y que no sean de Microsoft a los desarrolladores la construcción real de las cosas, con lo que la mayoría de Microsoft-beta de la tecnología. Como tal, el zumbido tiende a hacer que parezca que es más a lo largo de la infraestructura a su alrededor (la documentación, la orientación de los patrones, etc.). De ser realmente utilizable en este punto sólo amplifica el efecto.

58voto

Todd Smith Puntos 8297
 <% if (Model.PreviousPost || Model.NextPost) { %>
    <div class="pager">
    	<% if (Model.PreviousPost) { %>
    		<span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
    	<% } if (Model.NextPost) { %>
    		<span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
    	<% } %>
    </div>
<% } %>
 

Usted puede hacer otro post preguntando cómo hacer esto sin incluir la CSS embebido.

NOTA: ViewData.Model se convierte en modelo en la próxima versión.

Y con la ayuda de un control de usuario esto se convertiría en

 <% Html.RenderPartial("Pager", Model.PagerData) %>
 

donde PagerData se inicializa a través de un constructor anónimo en el controlador de acciones.

Edit: Tengo curiosidad por lo que su aplicación WebForm se vería para este problema.

26voto

Tom Anderson Puntos 7228

No estoy seguro de en qué momento la gente dejó de preocuparse por su código.

HTML es la más pública de su trabajo, hay un MONTÓN de desarrolladores que hay que utilizar el bloc de notas, notepad++, y otros llanura de los editores de texto para construir un montón de sitios web.

MVC se trata de obtener el control de los formularios web, trabajando en un entorno sin estado, y la aplicación de la Modelo de Controlador de Vista de modelo de diseño sin todo el trabajo extra que normalmente se lleva a cabo en una implementación de este patrón.

Si desea un control, el código limpio, y el uso de patrones de diseño MVC, esto es para ti, si no te gusta trabajar con etiquetas, no importa cómo malformaciones su margen de beneficio se presenta, a continuación, utilizar ASP.Net los Formularios Web.

Si no te gusta, te van a hacer casi todo el trabajo en el marcado.

EDITAR Debo indicar también que los Formularios Web y MVC tienen su lugar, yo no estaba en camino de afirmar que uno era mejor que el otro, sólo que cada MVC tiene la fuerza de la recuperación del control sobre el marcado.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X