¿Vale el tiempo el presentador de modelos de ASP.net?

Question

Estoy leyendo sobre el patrón de MVP de ASP.net durante este fin de semana y parece que incluso la tarea más simple requiere demasiado esfuerzo si hacerlo en el patrón de MVP, la recompensa parece estar en un proyecto más grande, pero creo que si Voy a seguir MVP. ¿Por qué no simplemente hacer el proyecto en ASP.net MVC?

La razón por la que estoy viendo el patrón de MVP es porque he notado que en todos mis proyectos de formularios web ASP.net hay una gran cantidad de código en el código que se encuentra detrás del manejo de eventos si tengo mucho control del servidor. en el formulario web, así que estaba buscando la forma de reducir eso y encontrar el patrón de MVP.

¿Vale la pena el esfuerzo por seguir el patrón de MVP o simplemente cambiar al ASP.net MVC?

Answer 1

Si inicia un nuevo proyecto, ASP.net MVC es una mejor opción. Pero si solo quieres refactorizar un proyecto existente como acabas de decir, entonces MVP es la opción porque no hay una manera fácil de convertir esos códigos de formularios web a MVC.

Answer 2

Recomendaría leer los siguientes dos enlaces para ponerte al día en MVP y MVC:

• Una excelente publicación en el blog de Gil Fink sobre las diferentes ventajas de MVP y MVC
• Una pregunta de StackOverFlow sobre cuál es la diferencia entre un MVP y MVC

¿Deberías cambiar?
Según lo que me ha dicho, le recomendaría que utilice el modelo de MVP pasivo mencionado en el artículo anterior.

Mis principales supuestos son:

1. Su trato con una base de código existente de aplicaciones de WebForms
2. Debe usar los controles de ThirdParty .Net para la funcionalidad existente
3. Estás trabajando en aplicaciones existentes y no tienes tiempo para volver a diseñarlas.
4. En cualquier aplicación web de ASP.Net en la que trabaje en el futuro, puede aplicar incrementalmente el MVP pasivo y obtener los beneficios de TDD de inmediato

Tu vista (codebehind + aspx) esencialmente se vuelve estúpida y simplemente realiza tareas simples:

• tomar información dada por el presentador
• responde a los eventos y proporciona información al presentador

He usado este modelo ampliamente para el desarrollo de Web Forms y no podía imaginar no poder realizar pruebas unitarias de mi modelo y el código de presentador. Una vez que establezca su modelo base, que no lleva mucho tiempo y que vea el poder de las pruebas unitarias, trabajar con Web Forms se vuelve agradable.

Algunos enlaces a material de MVP en los que se basa el modelo que he utilizado:

• Ejemplo sencillo del modelo MVP
• Modelo MVP simple para ASP.Net
• Un ejemplo de MVP y MVC para ASP.Net

También recomendaría que aprendas MVC para.
Cuando el tiempo lo permita, tome una aplicación existente y llévela a MVC. De esta manera, su único objetivo es conocer MVC y cuando mueva la lógica al patrón MVC, descubrirá cosas que implementó en los formularios de Web y que nunca pensó demasiado pero que ahora necesita resolver de otra manera. Gran manera de comparar los patrones y ver qué funciona para ti.

Espero que esto ayude, siéntase libre de hacer cualquier pregunta.

Answer 3

En mi opinión, la forma ideal de utilizar nuevas aplicaciones es MVC. Sin embargo, si ya tienes un montón de código utilizando WebForms, el patrón MVP es el camino a seguir.

Answer 4

Me gustaría Asp.Net MVC si fuera un proyecto nuevo, pero estoy de acuerdo, MVP podría ser un buen patrón para proyectos de formularios web heredados.

Aquí hay un ejemplo de mi blog: http: // www .unit-testing.net / CurrentArticle / How-to-Use-Model-View-Presenter-With-AspNet-WebForms.html

Answer 5

mi opinión personal es que si hay una gran cantidad de código en el código subyacente, todavía hay formas distintas de adoptar M-V-P para reducirlo, refactorizarlo y hacerlo comprobable.

si su página tiene una amplia interacción con el usuario (como los botones / enlaces habilitar / deshabilitar, los paneles y los controles que aparecen / desaparecen) M-V-P valdría la pena.