Mas sobre el Asp.net del futuro MVC y DotNetNuke

MVC y DotNetNuke

¿Y qué acerca de MVC? 

Habían realmente rumores flotando de que MVC ha alcanzado una etapa de madurez, donde, al igual que WebForms, será tratado más como una línea de productos de mantenimiento en el futuro (MVC4 puede ser en realidad la última iteración importante de este marco). Esto puede sonar alarmante para algunas personas que han adoptado recientemente MVC, pero realmente no debería, ya que ambos WebForms y MVC seguirán desempeñando un papel vital en la entrega de soluciones a los clientes. Ellos solos no serían el área principal en la que Microsoft está gastando la mayoría de sus recursos de investigación y desarrollo. Esa distinción, obviamente, irá a la Web API. Y cuando surge la pregunta de por qué no mejorar MVC para que funcione con la Web API, debes dar un paso atrás y mirar esto desde el nivel más alto para ver que ello realmente no tiene sentido. MVC es un marco de composición de páginas del lado del servidor; mientras que Web API promueve la composición de páginas del lado del cliente, con un fuerte enfoque en los servicios web. Con el fin de hacer que MVC trabaje bien con Web API, se requeriría una reescritura completa de MVC y al final del día, no habría ninguna ruta de actualización para las aplicaciones MVC existentes. Así que realmente no tiene mucho sentido de negocio.

Entonces, ¿qué tiene esto que ver con DotNetNuke?

Bueno, alrededor de 8-12 meses atrás nos dimos cuenta que la industria de software tendía hacia los servicios web y el desarrollo del lado del cliente. Hemos decidido utilizar un modelo “híbrido” el cual proporcionaría compatibilidad para los módulos existentes, mientras que al mismo tiempo sirva de puente para los desarrolladores que quisieran utilizar técnicas de web más modernas. Los clientes que gustan de la productividad y la familiaridad de WebForms pueden continuar construyendo módulos personalizados utilizando el enfoque tradicional. Sin embargo, en DotNetNuke 6.2 también introdujimos un nuevo Marco de Servicios que en realidad está construido en la cima de MVC2 (lo elegimos para aprovechar MVC porque tenía la más intuitiva y ligera implementación de REST en la pila. NET). El Marco de Servicios nos ha permitido construir algunas características interactivas enriquecidas en DotNetNuke 6.2, incluyendo el Centro de Mensajes y Notificación (Messaging and Notification Center) y el Alimentador de Actividades (Activity Feed). Pero en base a donde sabemos que Microsoft se está dirigiendo, tiene sentido para la próxima gran versión de DotNetNuke (que se espera que sea lanzado a finales de 2012) migrar de MVC2 a Web API. Esto probablemente se traducirá en algunos cambios importantes en el Marco de Servicios, pero creemos que es la mejor manera de asegurar que la plataforma siga siendo muy moderna y relevante. El hecho de que nuestra estrategia de desarrollo este perfectamente alineada con la estrategia “One ASP.NET” de Microsoft significa que nuestros clientes y la comunidad de desarrolladores pueden estar confiados en sus inversiones actuales y futuras en la plataforma DotNetNuke.