Volviendo a ASP.Net Webforms desde ASP.Net MVC. ¿Recomendar patrones / arquitecturas?

Para muchos de ustedes, esto parecerá una pregunta ridícula, pero lo pregunto porque tengo poca o ninguna experiencia con ASP.Net Webforms . Fui directamente a ASP.Net MVC.

Ahora estoy trabajando en un proyecto en el que estamos limitados a .Net 2.0 y Visual Studio 2005.

Me gustó la separación clara de las preocupaciones al trabajar con ASP.Net MVC, y estoy buscando algo para hacer que los formularios web sean menos insoportables. ¿Hay algún patrón o práctica recomendada para las personas que prefieren asp.net MVC, pero están atrapados en .net 2.0 y visual studio 2005?

Recomendaría Model View Presenter (MVP). Usamos esto en una aplicación reciente de WebForms y aumentó nuestra capacidad de prueba y nos permitió imponer la separación de las preocupaciones.

http://msdn.microsoft.com/en-us/magazine/cc188690.aspx es un gran artículo de Jean Paul Boodhoo sobre este patrón; La descarga del código también es buena. Sin embargo, es posible que no necesite DTO e interfaces para DTO.

Otro buen artículo es este en codeproject.com: http://www.codeproject.com/KB/architecture/ModelViewPresenter.aspx

Editar: también hay un marco llamado MVP de WebForms, pero no sé mucho al respecto.

Le recomendaría que comprenda el ciclo de vida de la página de .net 2.0

Puede que valga la pena ver estos videos , aunque no todos son gratuitos, pero al menos este será un buen comienzo para usted ... La cuestión es que esto le dará una idea sobre qué investigar más adelante.

Como ya habrá descubierto que necesitaría desaprender un par de cosas que aprendió con ASP.NET MVC (por cierto, lo mismo sucede cuando una persona de ASP.NET intenta aprender ASP.NET MVC). Todavía puede implementar el patrón MVC en ASP.NET, pero la separación de Ver y Modelo está muy borrosa en ASP.NET debido a la arquitectura de eventos / publicación posterior de la página.

En mi opinión, la mayor parte de su nuevo aprendizaje estará relacionado con el ciclo de vida de la página y los eventos y controles. Las cosas habituales Las interacciones Session, Cache, ViewState y DB siguen siendo las mismas.

HTH ...

Pedido frontal del controlador patrón y el controlador frontal de aplicación en Asp.Net. Haga estas cosas solo si su proyecto va a ser de buen tamaño. Hacer esto para un proyecto pequeño no justificará el ROI.

En un proyecto pequeño, puede intentar establecer algunas pautas. Por ejemplo: sin lógica empresarial, sin uso de sesión, etc. en el código subyacente.

Vea qué se adapta mejor a su caso. En cualquier caso, tenga la tentación de hacer más de ingeniería.

En los oscuros días de .NET 1.1 creé (supongo que como todos) una especie de sistema MVC para una aplicación que fue así.

Una página fue hecha para ser una especie de maestro 'falso'. Esto tenía algunas tuberías para mostrar menús, scripts, estilos, etc.

Las 'vistas' eran controles de usuarios individuales.

Había una tabla con información sobre cada vista. Por ejemplo, 'Producto' se cargaría ~/Controls/Product.ascxen un marcador de posición. La tabla también tenía un campo que contenía el nombre de tipo de la clase de modelo (como si). Cada modelo implementó una interfaz bien conocida. Esta clase fue instanciada usando Activator.CreateInstance()y llamada para inicializar, y luego pasó al control en sí (¿inversión de control?). El control luego llamó a varios métodos para obtener conjuntos de datos o cualquier otra cosa. La interfaz en sí se normalizó para tener los métodos CRUD habituales (lectura / escritura / lista / eliminación). También había una capa DAL / ORM debajo de esto.

No fue bonito, pero funcionó bien. Fue fácil probarlo y desarrollarlo, y la mayoría de los desarrolladores que se incorporaron se darían cuenta rápidamente. Sobre todo, fue relativamente simple de crear.