page - ¿Alguien a mi lado simplemente NO tiene ASP.NET MVC?
forms asp net core (24)
Comparado con Web Forms, MVC es a la vez un enfoque de bajo nivel para la generación de HTML con un mayor control sobre la salida de la página y un enfoque de mayor nivel y más orientado a la arquitectura. Permítanme capturar Web Forms y MVC y mostrar por qué creo que la comparación favorece los formularios web en muchas situaciones, siempre y cuando no caiga en algunas trampas clásicas de formularios web.
Formularios web
En el modelo de formularios web, sus páginas se corresponden directamente con la solicitud de página del navegador. Por lo tanto, si dirige a un usuario a una lista de libros, es probable que tenga una página en algún lugar llamada "Booklist.aspx" a la que lo dirigirá. En esa página, deberá proporcionar todo lo necesario para mostrar esa lista. Esto incluye código para extraer datos, aplicar cualquier lógica comercial y mostrar los resultados. Si hay una lógica arquitectónica o de enrutamiento que afecte a la página, también deberá codificar la lógica arquitectónica en la página. El buen desarrollo de Formularios Web generalmente implica el desarrollo de un conjunto de clases de soporte en una DLL separada (comprobable por unidad). Estas clases manejarán la lógica comercial, el acceso a los datos y las decisiones arquitectónicas / de enrutamiento.
MVC
MVC adopta una visión más "arquitectónica" del desarrollo de aplicaciones web: ofrece un andamio estandarizado sobre el cual construir. También proporciona herramientas para generar automáticamente clases de modelo, vista y controlador dentro de la arquitectura establecida. Por ejemplo, tanto en Ruby on Rails (solo "Rails" de aquí en adelante) como en ASP.NET MVC, siempre comenzará con una estructura de directorios que refleje su modelo general de arquitectura de aplicaciones web. Para agregar una vista, modelo y controlador, usará un comando como "Rails script / generate scaffold {modelname}" de Rails (ASP.NET MVC ofrece comandos similares en el IDE). En la clase de controlador resultante, habrá métodos ("Acciones") para Índice (lista de espectáculos), Mostrar, Nuevo y Editar y Destruir (al menos en Rails, MVC es similar). De forma predeterminada, estas acciones de "Obtener" solo combinan el Modelo y la ruta a un archivo de vista / html correspondiente en el directorio "Ver / {nombremodelo}" (tenga en cuenta que también hay acciones Crear, Actualizar y Destruir que manejan un "Publicación" y regresar a Indice o Mostrar).
El diseño de directorios y archivos es significativo en MVC. Por ejemplo, en ASP.NET MVC, el método Index para un objeto "Libro" probablemente solo tendrá una línea: "Return View ();" A través de la magia de MVC, esto enviará el modelo de Libro a la página "/View/Books/Index.aspx" donde encontrará el código para mostrar Libros. El enfoque de Rails es similar, aunque la lógica es un poco más explícita y menos "mágica". Una página de visualización en una aplicación de MVC generalmente es más simple que una página de formularios web porque no tienen que preocuparse tanto por el enrutamiento, la lógica comercial o el manejo de datos.
Comparación
Las ventajas de MVC giran en torno a una separación clara de preocupaciones y un modelo más limpio, más HTML / CSS / AJAX / Javascript centrado en producir su salida. Esto mejora la capacidad de prueba, proporciona un diseño más estandarizado y abre la puerta a un tipo de sitio web más "Web 2.0".
Sin embargo, también hay algunos inconvenientes importantes.
En primer lugar, si bien es fácil hacer funcionar un sitio de demostración, el modelo arquitectónico general tiene una curva de aprendizaje significativa. Cuando dicen "Convención sobre la configuración" suena bien, hasta que te das cuenta de que tienes una convención que vale la pena aprender. Además, a menudo es un poco enloquecedor descubrir lo que sucede porque confías en las llamadas mágicas en lugar de las explícitas. Por ejemplo, esa "Vista de retorno ();" llamar arriba? La misma llamada se puede encontrar en otras acciones, pero van a lugares diferentes. Si entiendes la convención de MVC, entonces sabes por qué se hace esto. Sin embargo, ciertamente no califica como un ejemplo de buen nombre o código fácilmente comprensible y es mucho más difícil para los nuevos desarrolladores que los formularios web (esto no es solo opinión: tuve un verano interno aprendiendo formularios web el año pasado). y MVC este año y las diferencias en la productividad fueron pronunciadas, a favor de las Formas Web). Por cierto, Rails es un poco mejor en este aspecto, aunque Ruby on Rails presenta métodos dinámicamente nombrados que también requieren un poco de seriedad.
En segundo lugar, MVC supone implícitamente que está construyendo un sitio web clásico al estilo CRUD. Las decisiones arquitectónicas y especialmente los generadores de códigos están diseñados para admitir este tipo de aplicaciones web. Si está construyendo una aplicación CRUD y desea adoptar una arquitectura probada (o simplemente no le gusta el diseño de la arquitectura), entonces probablemente debería considerar MVC. Sin embargo, si vas a hacer más que CRUD y eres razonablemente competente con la arquitectura, entonces MVC puede parecer una camisa de fuerza hasta que realmente domines el modelo de enrutamiento subyacente (que es considerablemente más complejo que simplemente enrutar en una aplicación de WebForms). Incluso entonces, sentí que siempre peleaba con la modelo y me preocupaban los resultados inesperados.
En tercer lugar, si no te importa Linq (ya sea porque tienes miedo de que Linq-to-SQL vaya a desaparecer o porque encuentras Linq-to-Entities ridículamente sobreproducido y con poca energía) entonces tampoco quieres para recorrer este camino, ya que las herramientas de andamio MVC de ASP.NET están construidas alrededor de Linq (este fue el asesino para mí). El modelo de datos de Rails también es bastante torpe en comparación con lo que puedes lograr si tienes experiencia en SQL (¡y especialmente si eres un experto en TSQL y procedimientos almacenados!).
En cuarto lugar, los proponentes de MVC a menudo señalan que las vistas de MVC tienen un espíritu más cercano al modelo HTML / CSS / AJAX de la web. Por ejemplo, "HTML Helpers" - las pequeñas llamadas de código en su página de vew que intercambian contenido y lo colocan en controles HTML - son mucho más fáciles de integrar con Javascript que los controles de Web Forms. Sin embargo, ASP.NET 4.0 introduce la capacidad de nombrar sus controles y, por lo tanto, elimina en gran medida esta ventaja.
En quinto lugar, los puristas de MVC a menudo se burlan de Viewstate. En algunos casos, tienen razón al hacerlo. Sin embargo, Viewstate también puede ser una gran herramienta y una gran ayuda para la productividad. A modo de comparación, manejar Viewstate es mucho más fácil que tratar de integrar controles web de terceros en una aplicación MVC. Aunque la integración de control puede ser más fácil para MVC, todos los esfuerzos actuales que he visto adolecen de la necesidad de compilar un código (algo turbio) para vincular estos controles a la clase Controladora de la vista (es decir, para evitar el modelo MVC) )
Conclusiones
Me gusta el desarrollo de MVC de muchas maneras (aunque prefiero Rails a ASP.NET MVC de una vez). También creo que es importante no caer en la trampa de pensar que ASP.NET MVC es un "anti-patrón" de ASP.NET Web Forms. Son diferentes pero no completamente ajenos y ciertamente hay espacio para ambos.
Sin embargo, prefiero el desarrollo de formularios web porque, para la mayoría de las tareas , es más fácil hacer las cosas (la excepción es la generación de un conjunto de formularios CRUD). MVC también parece sufrir, en cierta medida, un exceso de teoría. De hecho, mire las muchas preguntas formuladas aquí en SO por personas que conocen ASP.NET orientado a páginas pero que están probando MVC. Sin excepción, hay mucho rechinar de dientes cuando los desarrolladores descubren que no pueden realizar tareas básicas sin saltar por los aros o soportar una gran curva de aprendizaje. Esto es lo que hace que Web Forms sea superior a MVC en mi libro: MVC te hace pagar un precio real en el mundo para obtener un poco más de capacidad de prueba o, peor aún, simplemente ser visto como genial porque estás usando la última tecnología.
Actualización: Me han criticado mucho en la sección de comentarios, algo bastante justo. Por lo tanto, he pasado varios meses aprendiendo Rails y ASP.NET MVC solo para asegurarme de que no me estaba perdiendo la próxima gran cosa. Por supuesto, también ayuda a garantizar que ofrezco una respuesta equilibrada y adecuada a la pregunta. Debe saber que la respuesta anterior es una reescritura importante de mi respuesta inicial en caso de que los comentarios no estén sincronizados.
Mientras miraba más de cerca a MVC, pensé, por un momento, que terminaría con un gran mea culpa. Al final, llegué a la conclusión de que, si bien creo que necesitamos gastar mucha más energía en la arquitectura y capacidad de prueba de Web Forms, MVC realmente no responde la llamada. Entonces, un abundante "gracias" a la gente que brindó críticas inteligentes de mi respuesta inicial.
En cuanto a aquellos que vieron esto como una batalla religiosa y que inexorablemente diseñaron inundaciones de votaciones negativas, no entiendo por qué te molestas (más de 20 votos a favor en segundos en cuestión de ocasiones no es normal). Si está leyendo esta respuesta y se pregunta si hay algo verdaderamente "incorrecto" en mi respuesta dado que el puntaje es mucho más bajo que algunas de las otras respuestas, puede estar seguro de que dice más acerca de algunas personas que están en desacuerdo que el sentido general de la comunidad (en general, este ha sido votado más de 100 veces).
El hecho es que a muchos desarrolladores no les importa MVC y, de hecho, esta no es una visión minoritaria (incluso dentro de MS, como parecen indicar los blogs).
He estado jugando con ASP.NET MVC desde el CTP, y me gustan muchas cosas que hicieron, pero hay cosas que simplemente no entiendo.
Por ejemplo, descargué beta1, y estoy armando un pequeño sitio personal / currículo / blog con él. Aquí hay un fragmento de la vista ViewSinglePost:
<%
// 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> <%
}
%>
¡Asqueroso! (También tenga en cuenta que el HTML allí es HTML de marcador de posición temporal, haré un diseño real una vez que la funcionalidad esté funcionando) .
¿Estoy haciendo algo mal? Porque pasé muchos días oscuros en ASP clásico, y esta sopa de etiquetas me lo recuerda fuertemente.
Todo el mundo predica cómo puedes hacer HTML más limpio. ¿Adivina qué? El 1% de todas las personas miran el HTML entregado. Para mí, no me importa si Webforms arruina mi sangría en el HTML renderizado, siempre que tenga un código que sea fácil de mantener ... ¡Esto no es así!
Entonces, conviértanme, un tipo duro de webforms, ¿por qué debería abandonar mis páginas ASPX formadas para esto?
Editar: En negrita la línea "temp temp / css" para que la gente se enoje al respecto.
Creo que te faltan algunas cosas. Primero, no hay necesidad de Response.Write, puede usar las etiquetas <%= %> . En segundo lugar, puede escribir sus propias extensiones HtmlHelper para realizar acciones comunes. En tercer lugar, un poco de formato ayuda mucho. En cuarto lugar, todo esto probablemente se atascaría en un control de usuario para ser compartido entre varias vistas diferentes y, por lo tanto, el margen total en la vista principal es más limpio.
Le garantizo que el margen de beneficio aún no es tan limpio como a uno le gustaría, pero podría limpiarse considerablemente mediante el uso de algunas variables temporales.
Ahora, eso no es tan malo y sería aún mejor si no tuviera que formatearlo para SO.
<%
var PreviousPost = ViewData.Model.PreviousPost;
var NextPost = ViewData.Model.NextPost;
// Display the "Next and Previous" links
if (PreviousPost != null || NextPost != null)
{
%>
<div>
<%= PreviousPost == null
? string.Empty
: Html.ActionLinkSpan("<< " + PreviousPost.Subject,
"view",
new { id = PreviousPost.Id },
new { style = "float: left;" } ) %>
<%= NextPost == null
? string.Empty
: Html.ActionLinkSpan( NextPost.Subject + " >>",
"view",
new { id = NextPost.Id },
new { style = "float: right;" } ) %>
<div style="clear: both;" />
</div>
<% } %>
Eche un vistazo a la publicación de Rob Conery. Supongo que lo voy a decir: Deberías aprender MVC
El gran problema con MVC es que se trata de un marco conceptual que ha existido por mucho tiempo, y se ha demostrado como una forma productiva y poderosa de construir tanto aplicaciones web como aplicaciones para estaciones de trabajo que se extienden horizontal y verticalmente. Va directamente al Alto y Smalltalk. Microsoft llega tarde a la fiesta. Lo que tenemos ahora con ASP.NET MVC es realmente primitivo, porque hay mucho que hacer para ponerse al día; pero maldita sea, están lanzando nuevos lanzamientos rápida y furiosamente.
¿Cuál fue el problema con Ruby on Rails? Rails es MVC. Los desarrolladores han estado convirtiendo porque, de boca en boca, se ha convertido en el camino para que los programadores sean productivos.
Es un gran negocio; MVC y el respaldo implícito de jQuery son puntos críticos para que Microsoft acepte que la plataforma neutral es crítica. Y lo que es neutral al respecto, es que a diferencia de las Formas Web, Microsoft no puede encerrarlo conceptualmente. Puede tomar todo su código C # y volver a implementarlo en otro idioma por completo (digamos PHP o Java, lo que quiera) porque es el concepto de MVC portátil, no el código en sí. (Y piense qué tan grande es que puede tomar su diseño e implementarlo como una aplicación de estación de trabajo con pocos cambios de código y sin cambios en el diseño. Inténtelo con Web Forms).
Microsoft ha decidido que Web Forms no será el próximo VB6.
La mayoría de las objeciones a ASP.NET MVC parecen centrarse en las vistas, que son uno de los bits más "opcionales" y modulares en la arquitectura. NVelocity , NHaml , Spark , XSLT y otros motores de visualización se pueden intercambiar fácilmente (y cada vez se ha vuelto más fácil). Muchos de ellos tienen una sintaxis MUCHO más concisa para hacer la presentación de la lógica y el formato, al tiempo que aún se da un control total sobre el HTML emitido.
Más allá de eso, casi todas las críticas parecen reducirse al etiquetado <%%> en las vistas predeterminadas y lo "feo" que es. Esa opinión a menudo está arraigada en el uso del enfoque de WebForms, que simplemente mueve la mayor parte de la fealdad ASP clásica en el archivo de código subyacente.
Incluso sin hacer que los códigos subyacentes sean "incorrectos", tiene cosas como OnItemDataBound en Repeaters, que es tan estéticamente feo, aunque solo de una manera diferente, que "sopa de etiquetas". Un bucle foreach puede ser mucho más fácil de leer, incluso con incrustaciones variables en la salida de ese bucle, particularmente si vienes a MVC desde otras tecnologías que no son de ASP.NET. Se necesita mucho menos Google-fu para entender el ciclo foreach que darse cuenta de que la forma de modificar ese campo en su repetidor es meterse con OnItemDataBound (y el nido de la rata de comprobar si es el elemento correcto para cambiar).
El mayor problema con el "spaghetti" basado en la sopa de etiquetas ASP era más acerca de empujar cosas como las conexiones de bases de datos entre el HTML.
Que sucedió hacerlo usando <%%> es solo una correlación con la naturaleza espagueti de ASP clásico, no causalidad. Si mantiene su lógica de vista en HTML / CSS / Javascript y la lógica mínima necesaria para hacer la presentación , el resto es sintaxis.
Al comparar un bit determinado de funcionalidad con WebForms, asegúrese de incluir todos los C # generados por el diseñador y el código subyacente C # junto con el código .aspx para asegurarse de que la solución MVC realmente no es, de hecho, mucho más simple. .
Cuando se combina con el uso juicioso de vistas parciales para bits de lógica de presentación repetibles, realmente puede ser agradable y elegante.
Personalmente, deseo que gran parte del contenido inicial del tutorial se centre más en este extremo de las cosas que casi exclusivamente en la inversión de control controlada por la prueba, etc. Mientras que el resto se enfrenta a los expertos, es más probable que los chicos en las trincheras objetar a la "sopa de etiquetas".
De todos modos, esta es una plataforma que todavía está en beta. A pesar de eso, se está poniendo mucho más despliegue y los desarrolladores que no son de Microsoft están construyendo cosas reales con él que la mayoría de la tecnología Microsoft-beta. Como tal, el rumor tiende a hacer que parezca que está más avanzado que la infraestructura que lo rodea (documentación, patrones de orientación, etc.). Ser realmente útil en este momento solo amplifica ese efecto.
Las dos principales ventajas del marco ASP.NET MVC sobre los formularios web son:
- Capacidad de prueba: la interfaz de usuario y los eventos en formularios web son casi imposibles de probar. Con ASP.NET MVC, las acciones del controlador de pruebas unitarias y las vistas que renderizan son fáciles. Esto tiene un costo en costos de desarrollo iniciales, pero los estudios han demostrado que esto vale la pena a largo plazo cuando llega el momento de refactorizar y mantener la aplicación.
- Mejor control sobre el HTML renderizado : Usted declara que no le importa el HTML renderizado porque nadie lo mira. Esa es una queja válida si ese fuera el único motivo para tener un formato HTML adecuado. Existen numerosas razones para querer HTML formateado adecuadamente, que incluye: SEO, la capacidad de usar identificadores de id con más frecuencia (en css y javascript), huellas de página más pequeñas debido a la falta de viewstate y ids ridículamente largos (ctl00_etcetcetc).
Ahora bien, estas razones realmente no hacen que ASP.NET MVC sea mejor o peor que los formularios web en blanco y negro. ASP.NET MVC tiene sus fortalezas y debilidades, al igual que los formularios web. Sin embargo, la mayoría de las quejas sobre ASP.NET MVC parecen provenir de una falta de comprensión sobre cómo usarlo en lugar de defectos reales en el marco. La razón por la cual su código no se siente bien o no se ve bien podría deberse a que tiene varios años de experiencia en formularios web y solo a uno o dos meses de experiencia ASP.NET MVC.
El problema aquí no es tanto que ASP.NET MVC se mueva o apesta, sino que es nuevo y hay muy poco acuerdo sobre cómo usarlo correctamente. ASP.NET MVC ofrece un control mucho más preciso sobre lo que ocurre en su aplicación. Eso puede hacer que ciertas tareas sean más fáciles o más difíciles dependiendo de cómo las aborde.
MVC le brinda más control sobre su producción, y con ese control existe un mayor riesgo de escribir HTML mal diseñado, etiquetar sopa, etc.
Pero al mismo tiempo, tiene varias opciones nuevas que no tenía antes ...
- Más control sobre la página y los elementos dentro de la página
- Menos "basura" en su salida, como el ViewState o ID excesivamente largos en los elementos (no me malinterpreten, me gusta el ViewState)
- Mejor capacidad para hacer programación del lado del cliente con Javascript (¿Aplicaciones Web 2.0 alguien?)
- No solo MVC, pero JsonResult es astuto ...
Ahora bien, eso no quiere decir que no puedas hacer nada de esto con WebForms, pero MVC lo hace más fácil.
Todavía uso WebForms para cuando necesito crear rápidamente una aplicación web, ya que puedo aprovechar los controles del servidor, etc. WebForms oculta todos los detalles de las etiquetas de entrada y los botones de envío.
Tanto WebForms como MVC son absolutamente basura si se es descuidado. Como siempre, una planificación cuidadosa y un diseño bien pensado darán como resultado una aplicación de calidad, independientemente de si es MVC o WebForms.
[Actualizar]
Si te sirve de consuelo, MVC es solo una tecnología nueva y en evolución de Microsoft. Ha habido muchas publicaciones que WebForms no solo permanecerá, sino que continuará desarrollándose para ...
... y así...
Para aquellos preocupados por la ruta que MVC está tomando, sugiero darles a "los muchachos" sus comentarios. ¡Parece que están escuchando hasta ahora!
No estoy seguro de en qué momento las personas dejaron de preocuparse por su código.
HTML es la visualización más pública de su trabajo, hay MUCHOS desarrolladores que usan Notepad, Notepad ++ y otros editores de texto plano para crear muchos sitios web.
MVC se trata de recuperar el control de los formularios web, trabajar en un entorno sin estado e implementar el patrón de diseño de Model View Controller sin todo el trabajo adicional que normalmente tiene lugar en una implementación de este patrón.
Si desea control, código limpio y para usar patrones de diseño MVC, esto es para usted, si no le gusta trabajar con marcado, no se preocupe por el mal formato que tiene su marcado, entonces use los formularios web ASP.Net.
Si no te gusta tampoco, definitivamente estarás haciendo casi tanto trabajo en el marcado.
EDITAR I También debería decir que Web Forms y MVC tienen su lugar, de ninguna manera dije que uno era mejor que el otro, solo que cada MVC tiene la fuerza de recuperar el control sobre el marcado.
Oye, he estado luchando con cambiar a MVC también. Absolutamente no soy un fanático de ASP clásico y el renderizado MVC me recuerda muchos de esos días. Sin embargo, cuanto más utilizo MVC, más crece en mí. Soy un tipo de webforms (como muchos otros) y me he pasado los últimos años acostumbrándome a trabajar con datagrids, etc. Con MVC se lo quitan. Las clases de HTML Helper son la respuesta.
Hace poco pasé 2 días tratando de encontrar la mejor manera de agregar paginación a una "cuadrícula" en MVC. Ahora, con formularios web, podría batir esto en poco tiempo. Pero diré esto ... una vez que construí las clases de ayuda de paginación para MVC, se volvió extremadamente simple de implementar. Para mí, incluso más fácil que los formularios web.
Habiendo dicho eso, creo que MVC será mucho más amigable para los desarrolladores cuando haya un conjunto consistente de HTML Helpers. Creo que vamos a comenzar a ver un montón de clases de ayuda HTML emergentes en la web en el futuro cercano.
I can''t speak directly to the ASP.NET MVC project, but generally speaking MVC frameworks have come to dominate web application development because
They offer a formal separation between Database Operations,"Business Logic", and Presentation
They offer enough flexibility in the view to allow developers to tweak their HTML/CSS/Javascript to work in multiple browsers, and future versions of those browsers
It''s this last bit that''s the important one. With Webforms, and similar technologies, you''re relying on your vendor to write your HTML/CSS/Javascript for you. It''s powerful stuff, but you have no guarantee that the current version of Webforms is going to work with the next generation of web browsers.
That''s the power of the view. You get full control over your application''s HTML. The downside is, you need to be disciplined enough to keep the logic in your views to a minimum, and keep the template code as simple as you possibly can.
So, that''s the trade-off. If Webforms are working for you and MVC isn''t, then keep using Webforms
I was hoping to see a post from Phil Haack, but it wasnt here so I just cut and paste it from http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should-learn-mvc/ in the comments section
Haacked - April 23, 2009 - Rob, you''re a riot! :) I do find it funny when people write spaghetti code in MVC and then say "look! Spaghetti!" Hey, I can write spaghetti code in Web Forms too! I can write it in rails, PHP, Java, Javascript, but not Lisp. But only because I can''t yet write anything in Lisp. And when I do write spaghetti code I don''t look at my plate glumly expecting to see macaroni. The point people often make when comparing it to classic ASP is that with classic ASP people tended to mix concerns. Pages would have view logic with user input handling mixed in with model code and business logic all mixed up in one. That''s what the spaghetti was about! Mixing concerns all in one big mess. With ASP.NET MVC, if you follow the pattern, you''re less likely to do it. Yeah, you still might have a bit of code in your view, but hopefully that''s all view code. The pattern encourages you to not put your user interaction code in there. Put it in the controller. Put your model code in a model class. Ahí. No spaghetti. It''s O-Toro Sushi now. :)
I''ll admit that I don''t get asp.net MVC yet. I''m trying to use it in a side project I''m doing but it''s going pretty slow.
Besides not being able to do things that were so easy to do in web forms I notice the tag soup. It really does seem to take a step backwards from that perspective. I keep hoping that as I learn it will get better.
So far I''ve noticed that the top reason to use MVC is to gain full control over your HTML. I also read that asp.net MVC is able to serve up more pages faster than web forms and probably related to this, the individual page size is smaller than an average web forms page.
I really don''t care what my HTML looks like as long as it works in the major browsers, but I do care how fast my pages load and how much bandwidth they take up.
I''ve been using MVC for since Preview 3 came out and while it is still has it''s growing pains it helps quite a bit in the area of team development. Try having three people work on a single webforms page and then you''ll understand the concept of banging your head on the wall. I can work with a developer who understands the design elements on the view page and our resident Linq god in making the model work while I put everything together in the controller. I''ve never been able to develop in a realm where the separation of concerns was so easy to achieve.
Biggest selling point of ASP.Net MVC - runs on the MVC stack.
That being said... your code is so much prettier than what I normally do with the view page. Also, one of the guys I work with is working on wrapping the HTML helper into a tag library. Instead of <%=Html.RandomFunctionHere() %> it works like
< hh:randomfunction / >
I just hope the MVC team gets around to it at some point because I''m sure they''d do a better job of it.
It''s funny because that''s what I said when I first saw webforms.
Java EE''s JSPs looked like this when they were first proposed - ugly scriptlet code.
Then they offered up tag libraries to make them more HTML tag-ish. The problem was that anybody could write a tag library. Some of the results were disastrous, because people embedded a lot of logic (and even style) into tag libraries that generated HTML.
I think the best solution is the JSP Standard Tag Library (JSTL). It''s "standard", HTML tag-ish, and helps prevent people from putting logic into pages.
An added benefit is that it preserves that line of demarcation between web designers and developers. The good sites that I see are designed by people with an aesthetic sense and designing for usability. They lay out pages and CSS and pass them on to developers, who add in the dynamic data bits. Speaking as a developer who lacks these gifts, I think we give something important away when we ask developers to write web pages from soup to nuts. Flex and Silverlight will suffer from the same problem, because it''s unlikely that designers will know JavaScript and AJAX well.
If .NET had a path similar to JSTL, I''d advise that they look into it.
Just thought I''d share how this sample looks with the shiny new Razor view engine which is default since ASP .NET MVC 3.
@{
var prevPost = ViewData.Model.PreviousPost;
var nextPost = ViewData.Model.NextPost;
}
@if (prevPost != null || nextPost != null) {
<div>
@if (prevPost != null) {
<span style="float: left;">
@Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id })
</span>
}
@if (nextPost != null) {
<span style="float: left;">
@Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id })
</span>
}
<div style="clear: both;" />
</div>
}
Any problem with that?
Also, you shouldn''t actually inline your CSS styles, should you? And why do you check for nullity in three places instead of just two? An extra div rarely hurts. Así es como lo haría:
<div>
@if (prevPost != null) {
@Html.ActionLink("<< " + prevPost.Subject, "view",
new { id = prevPost.Id, @class = "prev-link" })
}
@if (nextPost != null) {
@Html.ActionLink(nextPost.Subject + " >>", "view",
new { id = nextPost.Id, @class = "next-link" })
}
<div class="clear" />
</div>
Me too; I would spend my time on Silverlight rather than ASP.NET MVC. I have tried MVC 1.0 and have had a look at the latest 2.0 Beta 1 release a few day ago.
I (can)''t feel that how ASP.NET MVC is better than webform. The selling point of MVC are:
- Unit (test)
- Separate the design (view) and logic (controller + model)
- No viewstate and better element id management
- RESTful URL and more ...
But webform, by using code-behind.Theme, Skin, and Resource are already perfect to separate the design and logic.
Viewstate: client id management is coming on ASP.NET 4.0. I am only concerned about unit tests, but unit tests are not enough being a reason to turn me to ASP.NET MVC from webform.
Maybe I can say: ASP.NET MVC is not bad, but webform is already enough.
Most of my frustration with it is just not knowing how to do things "properly". Since it was released as a preview we''ve all had a bit of time to look at things, but they''ve been changing quite a bit. At first I was really frustrated but the framework seems workable enough to enable me to create extremely complex UI''s (read: Javascript) pretty quickly. I understand that you can do this with Webforms as I was doing it before but it was a huge pain in the butt trying to get everything to render correctly. A lot of times I would end up using a repeater to control the exact output and would end up with a lot of the spaghetti mess that you have above as well.
In an effort to not have the same mess, I''ve been using a combination of having domain, service layers, and a dto to transfer to the view. Put that together with spark, a view engine and it gets really nice. It takes a bit to setup but once you get it going, I''ve seen a big step up in the complexity of my applications visually, but its so stinking simple to do code wise.
I wouldn''t probably do it exactly like this but here''s your example:
<if condition="myDtp.ShowPager">
<div>
<first />
<last />
<div style="clear: both;" />
</div>
</if>
That''s pretty maintainable, testable, and tastes yummy in my code soup.
The takeaway is that clean code is really possible, but it''s a big ass shift from the way we were doing things. I don''t think everyone groks it yet though. I know I''m still figuring it out...
Now, I can only speak for myself here:
IMO, if you''re a die-hard (anything) then conversion isn''t for you. If you love WebForms that''s because you can accomplish what you need to, and that''s the goal of any too.
Webforms does a good job of abstracting HTML from the developer . If that''s your goal, stick with Web Forms. You have all the wonderful "click and drag" functionality that has made desktop development what it is today. There are many included controls (plus a wealth of third party controls) that can bring about different functionality. You can drag a "grid" that''s directly associated with a DataSource from your database; it comes with built in inline-editing, paging, etc.
As of right now, ASP.NET MVC is very limited in terms of third party controls. So again, if you like Rapid Application Development, where a lot of functionality is wired up for you, you should not try to get converted.
With all of this said, this is where ASP.NET shines: - TDD. Code is not testable, nuff said.
Separation of concerns. That is the backbone of the MVC pattern. I am fully aware that you can accomplish this in Web Forms. However, I like imposed structure. It was too easy in Web Forms to mix design and logic. ASP.NET MVC makes it easier for different members of a team to work on different sections of the application.
Coming from somewhere else: My background is CakePHP and Ruby on Rails. So, it is clear where my bias lies. It''s simply about what you''re comfortable with.
Learning Curve: To expand on the last point; I hated the idea of "templating" to change the functionality of different elements. I didn''t like the fact that a lot of the design was accomplished in the code behind file. It was one more thing to learn, when I was already intimately familiar with HTML and CSS. If I want to do something in an "element" on the page, I stick in a "div" or "span", slap an ID on it and off I go. In Web Forms I would have to go research how to do this.
Current State of Web "Design": Javascript libraries like jQuery are becoming more commonplace. The way that Web Forms mangles your IDs just makes implementation (outside of Visual Studio) more difficult.
More Separation (Design): Because a lot of the design is wired into your controls, it would be very difficult for an outside designer (without Web Forms) knowledge to work on a Web Forms project. Web Forms was built to be the end all and be all.
Again, much of these reasons stem from my unfamiliarity with Web Forms. A Web Forms project (if designed right) can have "most" of the benefits of ASP.NET MVC. But that''s the caveat: "If designed right". And that''s just something I don''t know how to do in Web Forms.
If you''re doing stellar work in Web Forms, you''re efficient and it works for you, that''s where you should stay.
Basically, do a quick review on both (try to find a unbiased source [good luck]) with a list of pros and cons, evaluate which one fit your goals and pick based on that.
Bottom line, pick the path of least resistance and most benefit to meet your goals. Web Forms is a very mature framework and will only get better in the future. ASP.NET MVC is simply another alternative (to draw in Ruby on Rails and CakePHP developers such as myself :P )
Steve Sanderson''s recently published book ''Pro ASP.NET MVC'' [1] [2] from Apress suggests another alternative -- creating a custom HtmlHelper extension. His sample (from Chapter 4 on page 110) uses the example of a paged list, but it can easily be adapted for your situation.
public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func<int, string> pageUrl)
{
StringBuilder result = new StringBuilder();
if (previous != null || next != null)
{
result.Append("<div>");
if (previous != null)
{
result.Append(@"<span class=""left"">");
TagBuilder link = new TagBuilder("a");
link.MergeAttribute("href", pageUrl(previous.Id));
link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject));
result.Append(link.ToString());
result.Append("</span>");
}
if (next != null)
{
if (previous != null)
{
result.Append(" ");
}
result.Append(@"<span class=""right"">");
TagBuilder link = new TagBuilder("a");
link.MergeAttribute("href", pageUrl(next.Id));
link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject));
result.Append(link.ToString());
result.Append("</span>");
}
result.Append("</div>");
}
return result.ToString();
}
You would call it in your view with code something like this:
<%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %>
The implementation ASP.NET MVC is horrible. The product plain sucks. I''ve seen several demos of it and I''m ashamed of MSFT... I''m sure the guys who wrote it are smarter than me, but it''s almost as if they don''t know what the Model-View-Controller is.
The only people I know who are trying to implement MVC are people who like to try new things from MSFT. In the demos I''ve seen, the presenter had an apologetic tone...
I''m a big fan of MSFT, but I have to say that I see no reason to bother with their implementation of MVC. Either use Web Forms or use jquery for web development, don''t choose this abomination.
EDITAR:
The intent of the Model-View-Controller architectural design pattern is to separate your domain from the presentation from the business rules. I''ve used the pattern successfully in every Web Forms project I''ve implemented. The ASP.NET MVC product does not lend itself well to the actual architectural design pattern.
Use a Facade Pattern to wrap all the logic for all the data you need to display and then use it as your generic in your view and then.... no more spaghetti code. http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
If you need more help [email protected]
While I fully agree that that is ugly markup, I think using the ugly view syntax to write off ASP.NET MVC as a whole is not fair. The view syntax has gotten the least attention from Microsoft, and I am fully expecting something to be done about it soon.
Other answers have discussed the benefits of MVC as a whole, so I will focus on the view syntax:
The encouragement to use Html.ActionLink and other methods that generate HTML is a step in the wrong direction. This smacks of server controls, and, to me, is solving a problem that doesn''t exist. If we are going to generate tags from code, then why bother using HTML at all? We can just use DOM or some other model and build up our content in the controller. Ok, that sounds bad, doesn''t it? Oh yes, separation of concerns, that is why we have a view.
I think the correct direction is to make the view syntax as much like HTML as possible. Remember, a well designed MVC should not only give you separation of code from content, it should let you streamline your production by having people who are expert in layout work on the views (even though they do not know ASP.NET), and then later as a developer you can step in and make the view mockup actually dynamic. This can only be done if if the view syntax looks very much like HTML, so that the layout folks can use DreamWeaver or whatever the current popular layout tool is. You might be building dozens of sites at once, and need to scale in this way for efficiency of production. Let me give an example of how I could see the view "language" working:
<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
<a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span>
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
<a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span>
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />
Esto tiene varias ventajas:
- looks better
- more concise
- no funky context switching betwen HTML and <% %> tags
- easy to understand keywords that are self-explanatory (even a non-programmer could do this - good for parallelization)
- as much logic moved back into controller (or model) as possible
- no generated HTML - again, this makes it very easy for someone to come in and know where to style something, without having to mess around with Html. methods
- the code has sample text in it that renders when you load the view as plain HTML in a browser (again, good for layout people)
So, what exactly does this syntax do?
mvc:inner="" - whatever is in the quotes gets evaluated and the inner HTML of the tag gets replaced with the resulting string. (Our sample text gets replaced)
mvc:outer="" - whatever is in the quotes gets evaluated and the outer HTML of the tag gets replaced with the resulting string. (Again, sample text gets replaced.)
{} - this is used for inserting output inside of attributes, similar to <%= %>
mvc:if="" - insde the qoutes is the boolean expression to be evaulated. The close of the if is where the HTML tag gets closed.
mvc:else
mcv:elseif="" - ...
mvc:foreach
<% 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>
<% } %>
Puede hacer otra publicación preguntando cómo hacer esto sin incluir el CSS embebido.
NOTA: ViewData.Model se convierte en Model en la próxima versión.
Y con la ayuda de un control de usuario esto se convertiría
<% 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 cómo se vería la implementación de WebForm para este problema.