2009-04-06 15 views
13

Ahora he completado mi primera aplicación web utilizando ASP.NET MVC y, en general, todavía no entiendo por qué esto está recibiendo todos los elogios y la gloria. Tal vez estoy siendo terco. Sé que lo que hace que MVC sea excelente es que obliga a la separación entre la capa de presentación y el objeto comercial o la capa de datos junto con su operación sin estado. También sé que cuando trabajas con la vista, parece que el código es menos legible (mira mi ejemplo a continuación).ASP.NET MVC> ASP.NET WebForms, ¿Por qué?

Así que supongo que mi pregunta es ... Si la separación es la preocupación, ¿por qué no solo separarnos?

Web Forms Ver Código:

//UI 
<h2><asp:Label ID="lblPageHeader" runat="server" /></h2> 

Web Forms código subyacente:

//CODE BEHIND 
this.lblPageHeader.Text = myObject.Header; 

MVC código Ordenar:

//UI 
<h2><%= Html.Encode(Model.PageTitle) %></h2> 

Código controlador MVC:

index = new Index 
{ 
    PageText = sb.ToString(), 
    PageTitle = "WELCOME" 
}; 
return View(index); 

Una vez más, podría estar siendo terco, pero una de las cosas que más me han gustado en WebForms es la facilidad para establecer las propiedades del objeto como DataSources y valores de texto. Parece que esto es completamente diferente en MVC y menos legible, lo que hace que me pregunte sobre el mantenimiento a largo plazo.

EDIT Después de examinar los modelos mecanografiados, creo que la legibilidad del código se mejora sustancialmente.

+0

@tweakt - gracias por la edición! Buena atrapada. – RSolberg

Respuesta

14

ASP.NET MVC Best Practices, Tips and Tricks

que iba a escribir:

<h2><%= Html.Encode(Model.Title) %></h2> 

(que es posible con la ayuda de las vistas con tipo)

en lugar de

<h2><%= Html.Encode((MyApp.MyObject)ViewData["PageObject"].Header) %></h2> 

Creo que es todo acerca de cómo usarlo Si está más contento con ASP.NET clásico, entonces tal vez sea una mejor idea quedarse con él. Además, también puedes tomar cosas buenas de ASP.NET MVC world (como UI y separación Lógica) y llevarlas al clásico ASP.NET.

+0

Mientras que "cómo lo usa" parece que siempre tiene sentido y es aplicable para todo, realmente no hace nada para abordar la cuestión ... No sabía acerca de las vistas mecanografiadas. Estoy investigando esos. – RSolberg

+0

Vistas mecanografiadas FTW! No estoy seguro de cuándo volvería a usar una vista no tipada. – Webjedi

2

Por supuesto, un ejemplo simple va a ser muy claro y legible sin importar cómo lo haga. Supuestamente, la ventaja de MVC se vuelve más evidente a medida que escala la complejidad.

Además, resulta que el modelo de formularios web no es tan bueno para sitios de Internet públicos de gran volumen. ViewState más el costoso ciclo de vida de la página en un sitio normal de formularios web puede hacer que la escalabilidad sea un desafío (no imposible, sino desafiante). Por el contrario, en un int ra los usuarios del sitio de red generalmente tienen un ancho de banda de subida mucho mayor (ViewState funciona mejor) y el volumen está mucho mejor controlado. Así que los formularios web realmente funcionan bien allí.

+0

¿ASP.NET MVC no persiste en el estado del cliente? Si es así, ¿utiliza algo que no sea un campo de formulario oculto? (por ejemplo, cookies, etc.) Puede desactivar el estado de vista en ASP.NET si es demasiado grande (y trace.axd le dice su tamaño) ... –

+0

MVC no hace los controles de usuario de la misma manera , lo que hace que los problemas de estado de vista que se ven de vez en cuando en los formularios web prácticamente no existan. Sí, puede desactivar ViewState en formularios web, pero tampoco recibirá el tratamiento completo de formularios web. De hecho, ME GUSTA webforms la mayor parte del tiempo :) –

+0

Ahhh, tendré que echar un vistazo a ASP.NET MVC. Solía ​​desactivar viewstate por defecto y luego activarlo para los controles que lo necesitaban. Procedente de PERL cgi-scripts ViewState era un maldito regalo del cielo! –

0

También estoy tomando una actitud de esperar y ver acerca de ASP.NET MVC (junto con Entity framework y WPF por razones de diferencias).Soy un gran admirador de MVC en general, pero estoy un poco preocupado por envolver algo tan general como un marco de desarrollo web en las limitaciones de un patrón. Un patrón muy útil pero aún solo 1 de muchos.

Un desarrollador experto puede implementar MVC en prácticamente cualquier idioma. Entonces MVC puede ser una excelente manera de evitar que los desarrolladores menos capacitados (todos somos esto en algún momento, como cuando estamos aprendiendo un framework) cometan errores atroces. Dado que el patrón funciona bien en una amplia gama de escenarios que podrían hacer que sea un beneficio neto.

Por otro lado, para los desarrolladores expertos puede ser como ruedas de entrenamiento en un ciclista olímpico ... Redundante y más de un dolor que una bendición.

+0

debería leer este artículo :) www.artima.com/weblogs/viewpost.jsp?thread=104707 –

2

Es cierto que debe hacer más en MVC para obtener algunas de las mismas funciones básicas MUY automáticas a las que se acostumbró en WebForms.

Sin embargo, a la larga terminas con más control.

El principal problema de acerca de WebForms es el escenario completo de PostBack, y cuántos aros tiene que pasar para implementar algo simple que WebForms no pensó. Un excelente ejemplo es mi pregunta relacionada con WebForms: Is there any native way in ASP.NET to do a "success message"?

Quería hacer un mensaje "Grabar guardado" o "Nuevo registro agregado" en una aplicación WebForms. Resulta que tienes que hacer algunas cosas realmente aterradoras solo para que funcione esta funcionalidad simple, porque no tienen una forma normal de hacer esto en WebForms, y para hacer un método personalizado, estás luchando contra la funcionalidad oculta en PostBack.

En MVC, esto no sería un problema. Todavía tendría que escribir la funcionalidad de forma manual, pero tendría mucho más control sobre el estado de su página.

+0

Una etiqueta vacía que se establece (y posiblemente de color verde) no haría esto? Solía ​​usar el panel de formulario vs patrón de panel de éxito: una vez que el formulario se envió correctamente, el panel de formulario se hace invisible y el panel de éxito se hace visible (con el mensaje de éxito verde) –

+0

Estoy de acuerdo con Arnshea - en mi página maestra tengo métodos ShowError, ShowSuccess y un lugar donde/cómo mostrar cosas como esta. – Rashack

+0

¿Han visto la entrada y sus respuestas antes de votarme? No me pareció tan simple. – danieltalsky

2

Creo que solo puede sentir la diferencia después de haber estado en un gran proyecto y haber visto cuánto desorden podría causar el enfoque de WebForms.

Cuando haya visto una página que contiene múltiples componentes, controles de usuario, algunos de ellos viviendo vidas independientes como ocultar/mostrar o habilitarse/deshabilitarse, todas estas reglas pasan a través de múltiples capas de control que no pueden rastrearse hasta que Ha estado en un proyecto durante muchos años (o al menos ha fumado algo muy bueno antes de sumergirse con el depurador :)), comienza a apreciar la posibilidad de un flujo de control claramente definido cuando ve cómo sus datos definen con qué componentes qué propiedades se representan en una página.

También me encantaron los WebForms desde hace mucho tiempo. Tampoco me gustaron las primeras semanas/meses de MVC exactamente por las mismas razones que expusiste. Después de haber hecho algo de codificación y poder comparar la experiencia, comencé a disfrutar de MVC.

Aún así, hay algunas áreas donde el enfoque MVC sería mucho más complicado y crearía más desorden de lo que lo haría WebForms.

Llegará con el tiempo. No realmente hace mucho tiempo. :)

8

No es una respuesta completa, pero una gran preocupación es la capacidad de prueba de los formularios ASP.NET, o la falta de ellos. Probando la lógica de la interfaz de usuario de lo que se muestra y cómo. Con los formularios ASP.NET, solo le queda el código subyacente.

Ahora, MVC no es para todos. Es posible que desee buscar en MVP (Model-View Presenter) para ASP.NET Forms, ya que utiliza conceptos MVC muy similares, excepto que el presentador tiene el control de cambiar las partes internas de la vista.

Pero, la capacidad de prueba es realmente una gran ventaja para probar su código. Tal como whawt sucede cuando alguien hace clic en el método de ChangePassword/acción:

[TestClass] 
public class AccountControllerTest 
{ 

    [TestMethod] 
    public void ChangePasswordPostRedirectsOnSuccess() 
    { 
     // Arrange 
     AccountController controller = GetAccountController(); 

     // Act 
     RedirectToRouteResult result = 
      (RedirectToRouteResult)controller.ChangePassword(
       "oldPass", "newPass", "newPass"); 

     // Assert 
     Assert.AreEqual("ChangePasswordSuccess" 
      , result.RouteValues["action"]); 
    } 
} 
+1

Nada le impide hacer exactamente lo mismo con los formularios web. Proyecto anterior, implementamos Model-View-Presenter, y todo fue probado en unidades. Requiere patrones y disciplina: MVC puede ayudar, pero no es obligatorio. –

+0

Usted es exactamente correcto John, y es por eso que mencioné MVP arriba. MVC/MVP, todo se basa en el patrón que implementa y que lo hace comprobable. Las aplicaciones típicas de Formularios ASP.NET no tienen ese nivel de separación de preocupación, por lo que las personas solo MyNameTextBox.Text = User.DisplayName y están listas. :( – eduncan911

+0

La implementación de un patrón como MVC/MVP introduce un conjunto de reglas o pautas a seguir. Sin esas pautas, el desarrollador de Joe Blow simplemente conectará el código y lo hará. – eduncan911

10

Lo bueno de ASP.NET MVC es que es no tratar de ocultar cómo funciona HTTP. Para comprender completamente ASP.NET MVC, debe comprender las tecnologías de la web.

Si bien los formularios web son adecuados siempre y cuando trabajes con sus puntos fuertes, en última instancia son una abstracción muy permeable cuando no es así. Si bien los inconvenientes de viewstate han sido bien discutidos en este punto, creo que es el intento extremadamente imprudente de imitar el comportamiento de Winforms que es el defecto subyacente: viewstate es simplemente un producto de eso.

Los controles web que se entregan con ASP.NET también dejan un (infierno de) mucho que desear, como puede atestiguar cualquiera que haya intentado crear un sitio web accesible. Los controles web muestran una falta total de comprensión sobre cómo se lleva a cabo el desarrollo frontend, y francamente son una desgracia.

Con ASP.NET MVC se eliminan todas esas tonterías. No está protegido de HTTP, HTML, CSS o JavaScript. Si llega a la fiesta con esas tecnologías, el marco se quita de en medio y le permite aprovecharlas. Si no, afortunadamente no intenta ayudarte a pretender que no existen.

0

Creo que depende mucho de su fondo. Si ya estás familiarizado con algo como Ruby-rails y/o Django, asp.net mvc tiene mucho más sentido.

También si ha estado haciendo sitios web en Html y CSS durante mucho tiempo, Mvc es mucho mejor ya que tiene un control total sobre la salida de html.

Si te sientes cómodo con asp.net solo sigue usándolo, no va a desaparecer :).

8

Una cosa (entre muchas) que me gusta de MVC es que elimina los controles del servidor web. Si bien muchos lo ven como algo grandioso sobre WebForms, he descubierto que una vez que superas las operaciones básicas se convierten en una pesadilla. Intentar hacer malabares con eventos de enlace de datos en cuadrículas con devoluciones y todo lo demás se convierte en la versión OO del código de spaghetti.

MVC requerirá que tenga un mejor conocimiento de los inquilinos básicos de desarrollo web (GET, POST, REQUEST, HTML, CSS, JAVASCRIPT), el resultado será mucho mejor. Véase mi gráfico de cómo creo que funciona MVC :-)

alt text http://www.baseestate.com/webformsmvc.gif

Cuestiones relacionadas