ASP.NET MVC vs. Web Client Software Factory (WCSF)

Question

Recientemente he estado investigando un poco sobre los diferentes tipos de arquitecturas de Model View, y necesito decidir cuál buscar para el futuro desarrollo interno. Como actualmente estoy trabajando en una tienda de Microsoft que tiene habilidades de ASP.NET, parece que mis opciones están entre ASP.NET MVC y WCSF (Monorail probablemente esté fuera del sistema ya que no sería compatible con Microsoft).

Después de leer the ASP.NET MVC framework, using the WCSF as a yardstick, recogí los siguientes puntos:

• ASP.NET MVC no puede utilizar los controles web que se basan en las devoluciones de datos, mientras que WCSF pueda.
• Tiene más control sobre las URL en un sitio ASP.NET MVC que en un sitio WCSF.
• Un sitio ASP.NET MVC probablemente sea más fácil de probar que una versión equivalente de WCSF.
• Parece que el WCSF todavía usa el código para controlar los eventos de IU en algunas circunstancias, pero ASP.NET MVC no lo permite.

¿Cuáles son algunas de las otras consideraciones?
¿Qué he entendido mal?
¿Hay alguien por ahí que haya usado ambos frameworks y tenga algún consejo?

Answer 1

ASP.NET MVC no puede usar controles web que se basan en las devoluciones, mientras que WCSF sí.

Debería pensar en WCSF como una guía sobre cómo usar la infraestructura existente de WebForms, especialmente al introducir Model-View-Presenter para ayudar a hacer cumplir la separación de inquietudes. También aumenta la capacidad de prueba del código resultante.

Tiene más control sobre las direcciones URL en un sitio ASP.NET MVC que en un sitio WCSF.

Si puede orientar 3.5 SP1, puede usar el nuevo sistema de enrutamiento con un sitio tradicional de WebForms. El enrutamiento no está limitado a MVC. Por ejemplo, eche un vistazo a Dynamic Data (que también se envía en 3.5 SP1).

Un sitio ASP.NET MVC probablemente sea más fácil de probar que una versión equivalente de WCSF.

Esto es cierto, ya que utiliza las nuevas clases de abstracciones HttpContext, HttpRequest, HttpResponse, etc. No hay nada inherentemente más comprobable sobre el patrón MVC que el patrón MVP. Ambos son ejemplos de "presentación separada", y ambos aumentan la capacidad de prueba.

Parece que el WCSF aún utiliza el código para controlar los eventos de la interfaz de usuario en algunas circunstancias, pero ASP.NET no permite esto.

En Model-View-Presenter, dado que el mundo exterior interactúa con las vistas (es decir, la URL apunta a la vista), las vistas responderán naturalmente a estos eventos. Deben ser lo más simples posible, ya sea llamando al presentador u ofreciendo eventos a los que el presentador puede suscribirse.

Model-View-Controller supera esta limitación haciendo que el mundo exterior interactúe con los controladores. Esto significa que sus puntos de vista pueden ser mucho más "tontos" sobre cosas que no son de presentación.

En cuanto a lo que debe utilizar, creo que la respuesta se reduce a cuál se adapta mejor a los objetivos de su proyecto. A veces WebForms y la disponibilidad de un proveedor de control de terceros ricos serán preferibles, y en algunos casos, la simplicidad sin procesar y el control HTML de grano fino favorecerán a MVC.

Answer 2

¿Por qué no conectar ambos a Northwind y ver cuál se adapta mejor para usted y su situación?

Answer 3

También podría considerar los antecedentes de sus desarrolladores (si alguno ya han sido identificados).

Si provienen de un fondo estricto de asp.net, estarán más cómodos con WCSF (aunque en mi experiencia, todavía tardaron unas semanas en sentirse realmente cómodos con MVP).

Si provienen de un fondo de java/rails, o han utilizado otras arquitecturas MVC antes, entonces obviamente estarán más contentos allí (y en mi experiencia se vuelven muy presuntuosos con cualquier otra cosa que no sea MVC).

Answer 4

Optamos por el WCSF después de hacer exactamente la misma evaluación. Sentimos que el patrón de MVP nos dio más opciones, es decir, la capacidad de usar controles de servidor. Nuestro equipo de desarrollo está compuesto principalmente por programadores de una infinidad de disciplinas, es decir, C++, Biztalk y web, etc., pero todos se centraron principalmente en el desarrollo de tipos de MS, por lo que la curva de aprendizaje en la adopción de los patrones no era tanto para nuestro equipo.

Estamos más que felices con nuestra elección.

Answer 5

No para comenzar una guerra de llama pero encontré que el WCSF es bastante intrincado. La elegancia y la simplicidad de MVC derriten a MVP, que se siente como un patrón que acaba de ser injertado en formularios web.

Answer 6

MVC es un paradigma mucho más simple y es más similar a cómo todos los demás marcos hacen el desarrollo web. WebForms es simplemente demasiado saltar por aros y demasiadas capas de abstracción para tratar de lograr la simplicidad. En mi humilde opinión, MVC será la arquitectura predeterminada de ASP.NET dentro de unos años, a medida que más y más personas se den cuenta de la simplicidad y facilidad de desarrollo y prueba que aporta con nosotros. He estado desarrollando MVC durante un año y medio y nunca pensé volver a WebForms en un nuevo proyecto.

Answer 7

Un sitio de ASP.NET MVC probablemente será más fácil de probar que una versión WCSF equivalente.

Esto es cierto, ya que utiliza las nuevas clases de abstracciones HttpContext, HttpRequest, HttpResponse, etc. No hay nada inherentemente más comprobable sobre el patrón MVC que el patrón MVP. Ambos son ejemplos de "Presentación separada", y ambos aumentan la capacidad de prueba de .

Esto es probablemente discutible, pero hay literatura que sugiere que usar un modelo de diseño MVP es más fácil de probar una unidad que un modelo de diseño MVC si tiene Vistas que están llenas de lógica. En resumen, en el modelo de diseño de MVP, el presentador está manejando el trabajo que podría ser manejado por la vista en el modelo de diseño de MVC. La lógica que podría estar contenida en MVC View no facilita las pruebas unitarias.Aquí hay algunas referencias a la literatura que he leído que cubrirían este concepto y las razones por las cuales mantener su luz de visualización es mejor por muchas razones, incluida la facilitación de las pruebas unitarias.

http://martinfowler.com/eaaDev/uiArchs.html

http://martinfowler.com/eaaDev/SupervisingPresenter.html

http://martinfowler.com/eaaDev/PassiveScreen.html