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.

Futuro del Asp.net

Futuro del Asp.net es la Web API

Sentado en un avión, camino a casa desde el Tech Ed 2012 desarrollado en Orlando, pensé que sería un buen momento para anotar algunos puntos clave de la conferencia de este año. Algunos de estos temas los he conocido desde la Cumbre de Microsoft MVPs en Redmond que se produjo a finales de febrero (pero debido a las restricciones de la NDA no pude compartirlos con la comunidad de desarrolladores en general) y algunos de ellos son el resultado de las interesantes conversaciones con una amplia variedad de expertos de la industria y empleados de Microsoft en la conferencia.

En primer lugar, vamos a viajar en el tiempo 4 años atrás, a la Cumbre de Microsoft MVPs del 2008. Microsoft enfrentó un cierto bochorno del debutante del mercado Ruby on Rails y respondió con un nuevo marco de desarrollo web de su propiedad, ASP.NET MVC. En la Cumbre ellos estimaron que MVC sólo sería aplicable a ~ 10% de todos los nuevos proyectos de desarrollo web. Basado en esa predicción me pregunté por qué ellos estaban invirtiendo tantos recursos considerables para un caso extremo relativo, pero mi suposición es que ellos sentían que era un caso extremo importante en el momento en que algunos de los más ruidosos Evangelistas .NET así como algunos emprendimientos de muy alto perfil (es decir, Twitter) habían anunciado públicamente su intención de usar Rails.

Microsoft hizo mucho ruido acerca de MVC. De hecho, enfocaron tanto de su mensajería y bombo publicitario alrededor de MVC que parecía que WebForms estaba esencialmente muerto. Sí, puede ser cierto que Microsoft continuaba invirtiendo en WebForms, pero desde una perspectiva externa realmente parecía que MVC era el único marco de trabajo recibiendo una atención real. Como resultado, MVC comenzó a ganar cuota de mercado. Una fuente interna de Microsoft me dijo que el uso de MVC ha crecido a un ritmo de alrededor de 5% por año, y ahora se sitúa en ~ 30%. Esencialmente por enfocar tanto esfuerzo de mercadotecnia en MVC, Microsoft realmente creó una demanda de mercado más grande para él. Esto se debe a que en el ecosistema de Microsoft hay algo de una mentalidad de subirse al carro entre los desarrolladores. Si Microsoft pasa mucho tiempo hablando de una tecnología específica, los desarrolladores tienen la percepción de que debe de ser muy importante. Así que en lugar de elegir la herramienta adecuada para el trabajo, a menudo eligen la herramienta con el mayor bombo publicitario y luego tratan de venderlo al cliente.

En 2010, escribí en mi blog sobre el hecho de que MVC no tenía ningún sentido de negocio para la plataforma DotNetNuke. Esto se debía a que nuestro ecosistema se basó en las extensiones de terceros que eran dependientes del modelo de WebForms. Si migrábamos el núcleo a MVC, significaría que todas las extensiones de terceros ya no serían compatibles, lo que sería una decisión de negocios irresponsable para nosotros hacer eso a costa de nuestros usuarios y clientes. Sin embargo, esto no impidió que el debate continúe ocurriendo en nuestro ecosistema. Es evidente que algunos desarrolladores habían bebido el brebaje de Microsoft sobre MVC y eran de la mentalidad que parafraseaba un viejo dicho escocés: “Si no es MVC, es basura”. Ahora, esta es una posición bastante ignorante que tomar ya que la mayor parte de los beneficios de MVC se puede lograr en WebForms con una arquitectura sólida y prácticas de codificación responsables. Separación limpia de intereses (SoC), pruebas unitarias y el control directo sobre los resultados de la página son posibles en el modelo de WebForms – sólo requiere constancia y disciplina.

Menús de Navegación

Menús de Navegación

Podemos crear menús de navegación para su sitio web utilizando el control menú deASP.NET.

?

1	<asp:Menu ID="Menu1" runat="server"></asp:Menu>

El control menú tiene ciertas propiedades que nos permiten adaptar a nuestro gusto y necesidad. Por default el control menú es un control vertical. Para nuestra página vamos a necesitar que sea horizontal.

?

1 2	Orientation="Horizontal" Orientation="Vertical"

Todo menú debe tener ítems que nos sirvan de acceso a las diferentes partes del sitio.

?

1	<Items></Items>

Dentro de los tags ítems debemos detallar los MenuItems que necesitamos.

?

1	<asp:MenuItem></asp:MenuItem>

Los menús se comportan en relación a una estructura de árboles normalmente organizados en diferentes niveles de una jerarquía. La primera rama es el root del menú y las siguientes son los sub menúes.

?

1 2 3 4 5 6 7 8 9

<asp:MenuItem> <asp:MenuItem> </asp:MenuItem> <asp:MenuItem> <asp:MenuItem /> <asp:MenuItem /> <asp:MenuItem /> </asp:MenuItem> </asp:MenuItem>

Vamos a armar un menú con tres opciones para nuestro sitio web y lo vamos a incluir en nuestra master page.

?

1 2 3 4 5 6 7

<asp:Menu ID="Menu1" runat="server" /> <Items> <asp:MenuItem NavigateUrl="~/Menu1.aspx" Text="Menu1" Value="1"/> <asp:MenuItem NavigateUrl="~/Menu2.aspx" Text="Menu2" Value="2"/> <asp:MenuItem NavigateUrl="~/Menu3.aspx" Text="Menu3" Value="3"/>    </Items> </asp:Menu>

ASP.NET permite agregarle estilo al control mediante determinadas propiedades del tab MENU.

?

1 2 3 4 5 6

BackColor="#B5C7DE" DynamicHorizontalOffset="2" Font-Names="Verdana" Font-Size="0.8em" ForeColor="#284E98" StaticSubMenuIndent="10px"

Estilos para las acciones:

?

1 2 3 4 5 6 7

<StaticSelectedStyle BackColor="#507CD1" /> <StaticMenuItemStyle HorizontalPadding="5px" VerticalPadding="2px" /> <DynamicHoverStyle BackColor="#284E98" ForeColor="White" /> <DynamicMenuStyle BackColor="#B5C7DE" /> <DynamicSelectedStyle BackColor="#507CD1" /> <DynamicMenuItemStyle HorizontalPadding="5px" VerticalPadding="2px" /> <StaticHoverStyle BackColor="#284E98" ForeColor="White" />

Nuestro menú y formato se ve de esta forma

?

1	Orientation="Vertical"

?

1	Orientation="Vertical"