¿Qué tecnología de desarrollo de Microsoft utilizar?

¿Qué tecnología de desarrollo de Microsoft utilizar?

Publicado en 18 noviembre, 2013de pepitosolis

Recientemente ha habido mucho movimiento en relación a las tecnologías para desarrollar de Microsoft, dejando a muchos desarrolladores ponderando en cuáles deberían enfocarse. La resistencia de Microsoft a dejar de lado tecnologías como Silverlight, y en vez de eso dejar que lentamente desaparezcan, sólo añade más confusión. Una manera de darse cuenta es revisar un documento poco conocido llamado Guía Tecnológica .NET para Aplicaciones de Negocios “.NET Technology Guide for Business Applications”. Fue publicado a comienzos de este año, la guía ofrece una comprensión de en dónde Microsoft intenta poner sus esfuerzos y qué tecnologías deberían ser evitadas.

Este resumen es un buen lugar para comenzar la exploración de Microsoft y las tecnologías relacionadas.

Tratar de dejar pronto Silverlight y Flash.

Mientras tecnologías antiguas .NET como WinForms y Web Forms han encontrado un lugar. Contenedores de RIA (Rich Internet Applications) tales como Silverlight y Flash están definitivamente de salida. Como se puede ver en la figura. Microsoft no quiere esperar los 10 años del ciclo de vida de Silverlight 5. Ellos intentan deshacerse de los contenedores RIA para finales del 2015.

Para aplicaciones de alto nivel, tecnologías completamente nativas son las preferidas. En el nivel más bajo, las capacidades de HTML5 se espera que continuen creciendo. Mientras no se está empujando a los desarrolladores a ir a un lado o al otro, aquí es lo que ellos tienen que decir sobre la transicion:

• Si estás haciendo la transición a aplicaciones nativas, puedes utilizar tus habilidades existentes y aún el código si apuntas a XAML/NET nativamente en cualquier dispositivo Windows. Las bibliotecas portátiles (Portable Libraries) permitirán compartir archivos binarios entre diferentes plataformas incluyendo Silverlight.
• Para aplicaciones basadas en navegador HTML5, Microsoft provee herramientas líderes y marcos de desarrollo para ayudarte a crear aplicaciones para cualquier dispositivo usando los últimos estándares. La interoperatibidad de Silverlight con HTML también permite una transición gradual a través de aplicaciones híbridas.

Móviles

3 opciones iguales pero diferentes para la tienda Windows 8

En el pasado Microsoft ha sido reacio a empujar a los desarrolladores hacia una tecnología específica cuando se trata de aplicaciones tienda Windows 8. La política no ha cambiado, el criterio número uno para escoger entre .NET/XAML, C++ y JavaScript/HTML5 es simplemente con cual el desarrollador se encuentra más familiarizado. Más allá de eso, ellos citan las ventajas en rendimiento de C++. La reusabilidad no es una gran preocupación porque las 3 plataformas son capaces de compartir código y recursos entre Windows Phone y aplicaciones Windows de escritorio.

Opciones nativas para Windows Phone

En Windows Phone las tecnologías reocmendadas son .NET y C++. Otra vez aquí hay una aprobación de la ventaja en rendimiento de C++, pero mayormente ellos les dicen a los desarrolladores que usen lo que les sea más familiar.

Aunque Windows Phone es compatible con PhoneGap/Apache Cordova, eso no es mencionado en ningún lado. Presumiblemente esto se debe a que ven a PhoneGap como algo que tiene peor rendimiento que .NET o C++ en dispositivos pequeños. En la conferencia Build 2013 el rendimiento fue de lejos el tópico más importante, dejando atrás otras consideraciones como usabilidad general, diseño visual y profunda integración con el sistema operativo.

Web Móvil: Todo menos Web Forms

Si buscamos escoger una solución basada en web para trabajar en todos los dispositivos móviles las opciones son numerosas. ASP.NET MVC con Modernizer es la recomendación de referencia, con la opción de construir una aplicación de una sola página (ASP.NET SPA) donde sea apropiado. Microsoft considera SPA a ser nada más que un patrón de diseño que una tecnología, con Knockout y Breeze siendo las librerías más recomendadas.

Para poner rápidamente aplicaciones de estilo CRUD (Create Read Update and Delete) LightSwitch está en la mesa. Esto ofrece poco control sobre el HTML producido pero no requiere el sobrecosto de que los desarrolladores tengan que construir sus propios diseños para varios tamaños de pantalla.

ASP.NET Web Pages son la cuarta opción ofrecida para web móvil. Basado en la sintáxis Razor esto ofrece una experiencia de desarrollo similar a los lenguages de script tales como PHP y el clásico ASP.

Lo que no se menciona es la vieja tecnología ASP.NET Web Forms. Mientra está aún en desarrollo activo y teoricamente capaz de crear HTML específico para un dispositvo, en la práctica Web Forms no llegó a realizar su máximo potencial. El HTML y JavaScript que genera tiende a ser ineficiente y el “View State”, el cual es parte integral para sus características más avanzadas puede rápidamente sobrecargar una conexión de red de un teléfono.

Servicios.

Desde que la mayoría de aplicaciones dependen de un almacenamiento de datos externo y procesamiento, el desarrollo del lado del servidor continua siendo una consideración importante. Hay actualmente 6 opciones de tecnologías que Microsoft considera viables.

Primera Elección: ASP.NET Web API

De acuerdo a Microsoft, la opción por defecto para nuevos proyectos debería ser ASP.NET Web API. Esto puede ser utilizado cuando los servicios que se van a desarrollar siguen los patrones REST (Representational State Transfer) y se supone que sea compatible con caches de internet como Akamai, Windows Azure CND, Level3, etc.

Cuando se utilice Web API los desarrolladores deben enfocarse en OData, lo cual estandariza la manera en que los extremos REST (REST endpoints) son expuestos y JSON.

Segunda Elección: WCF

Si no estás amarrado a ningún protocolo de transporte específico o formato de mensaje, WCF se le considera una opción más flexible que Web API. Tú puedes, por ejemplo, tomar ventaja de TCP o named pipes con mensajes binarios para un rendimiento mejorado. El lado malo es que trabajar con WCF puede ser difícil especialmente cuando quieres exponer datos en JSON u otro formato que no está basado en SOAP (Simple Object Access Protocol). WCF fue diseñado como un mecanismo de comunicación tipo RPC (Remote Procedure Call) y empresarial. Mientras un patrón de diseño tipo REST es posible, WCF no es la opción preferida.

WCF con OData

Si estás trabajando en una capa de servicio estilo CRUD y quieres utilizar WCF entonces WCF Servicios de datos es la manera. Esto comparte librerías OData con ASP.NET Web API y es a menudo utilizado con Entity Framework.

Servicios de Flujos de Trabajo (Workflow)

Los servicios workflow son un matrimonio entre Windows Workflow y WCF. La única razón para utilizar esto es si tus servicios ya están utilizando Windows Workflow internamente. Microsoft no cita ninguna otra razón para escoger esta opción.

SignalR y Comunicación de 2 vías.

Si estás usando solamente clientes basados en .NET, WCF ofrece muchas opciones para afinar la comunicación de 2 vías. Si quieres algo que soporte ambos .NET y clientes basados en web entonces SignalR es una opción tentadora.

De acuerdo con Microsoft, SignarlR puede escalar a “millones de usuarios”. Para clientes web SignalR utiliza WebSockets pero puede automáticamente hacer una regresión a viejos patrones como “long polling” (consulta larga) si es necesario.

SignalR también tiene un librería para clientes .NET, permitiendo que clientes web y clientes nativos compartan servicios.

LightSwitch, otro proveedor de OData

Es difícil indicar cuánto amor tiene Microsoft para OData. Acabamos de ver OData para ambos WCF y Web API, pero no termina allí. Aunque normalmente utilizado con clientes LightSwitch, podrías imaginar utilizar las capacidades del lado del servidor de LightSwitch para rápidamente generar una capa de servicio.

Microsoft asegura que LightSwitch no requiere codificación pero advierte que eso viene con una pérdida de flexibilidad.

Guía para aplicaciones de negocios pequeñas y medianas.

Microsoft escribió esta guía con estas metas en mente:

• Velocidad completa y “Tiempo a Mercado” más corto.
• Productividad y menores costos.
• Fácil para comenzar.
• Colaboración e integración con productos del mercado.
• Agilidad en la nube y oportunidades para reducción de costos.

Traducido esto significa, “hazlo rápido y hazlo barato”.

Aplicaciones Web para negocios pequeños/medianos

Para aplicaciones CRUD rápidas, Microsoft continúa empujando LightSwitch como la plataforma que hay que usar. Fue originalmente descrita como una herramienta para programadores principiantes. Muchos lo ven como un reemplazo de Acces multi-capas. Esa visión parece desvanecerse ya que LightSwitch está ahora siendo ofrecido más como una herramienta para departamentos de IT que necesitan rápidamente crear aplicaciones.

Lo siguiente es Web Forms. Sí, la venerable tecnología Web Forms está aún siendo recomendada para usar en nuevos proyectos. Microsoft lo ve como un terreno intermedio entre el fácil pero limitado LightSwitch y la complejidad de ASP.NET MVC. Con características tales como grillas ricas de datos. Web Forms son bien apropiadas para aplicaciones internas de una organización.

ASP.NET Web Pages son mencionadas pero brevemente. Si quieres más control sobre lo que ofrece Web Forms, ASP.NET MVC es la herramienta elegida. Aunque Microsoft advierte de su larga curva de aprendizaje.

Construyendo para el escritorio de Windows

Mientras todos los kits de herramientas basados en C++ como MFC (Microsoft Foundation Classes) y ATL/WTL (Active Template Libraty/Windows Template Library) están fuera de la lista, el original kit de herramientas .NET WinForms es aún considerado una opción viable junto con WPF (Windows Presentation Foundation). Ambos soportan conceptos modernos tales como enlace de datos (data binding), async/await y comunicación de dos vías usando WCF o SignalR

La elección entre WPF y WinForms involucra muchas consideraciones.

Primero es la dificultad. WinForms es mucho más fácil de entender que WPF, aún para desarrolladores avanzados. WinForms utiliza un simple enlace de datos y prefiere un clásico MVC o MVP. WPF por el contrario requiere que el usuario aprenda un complejo marco de enlace de datos para correctamente utilizar el patrón MVVP. Tener éxito con WPF también requiere conocimiento de diccionarios de recursos, convertidores, ICommands y XAML.

Si intentas también apuntar a Windows Phone o tienda Windows 8, vas a tener que aprender como usar XAML. En ese caso, comenzar con WPF hará más probable que se pueda compartir código entre plataformas.

La flexible máquina de visualización en WPF permite hacer aplicaciones que se ven mejor de lo que podría ser hecho generalmente con WinForms. Este tiene un costo ya que generalmente las aplicaciones WPF se ejecutan más lentamente que aplicaciones WinForms comparables.

Mencionado de pasada es el cliente de escritorio LightSwitch. Presumiblemente, éste no puede ofrecer nada que no esté disponible en su cliente web, por lo tanto no parece haber mucha razón para escogerlo.

Cliente-Servidor debería ser evitado.

Cuando Microsoft dice “cliente-servidor” ellos específicamente se refieren a aplicaciones que directamente se comunican con la base de datos. Aunque ellos saben que es aún un patrón muy común, ellos quieren que los nuevos proyectos utilicen un diseño de 3-capas con una capa de servicio que se encuentre en el medio, entre el cliente y la base de datos. Esto provee una mejor escalabilidad sobre el acceso directo a la base de datos y una manera para sobrepasar firewalls (corta-fuegos) y otros obstáculos. Además permite que la aplicación sea migrada a otras plataformas donde los controladores de la base de datos podrían simplemente no estar disponibles.

“Modernización” – Dejando el escritorio de Windows

Microsoft ofrece muchos consejos sobre como “modernizar” aplicaciones de escritorio. Este consejo es mayormente sobre alistar la aplicación para ser migrada a otras plataformas pero hay algunas guías que son útiles aunque no planees en dejar el escritorio de Windows. Aquí un resumen:

• Utiliza el patrón de diseño Model-View-ViewModel (MVVM). Plataformas de cliente de Microsoft (incluyendo WPF) hacen fácil construir aplicaciones utilizando el patrón MVVM. Con este patrón tienes una fuerte separación de visualización, estado y comportamiento, lo cual te ayudará a crear un código limpio y mantenible que puede ser fácilmente compartido entre múltiples dispositivos.
• Utiliza librerías de clases portátiles para la lógica del cliente. Las librerías portátiles .NET permiten que los binarios sean compartidos entre múltiples plataformas tales como el escritorio, aplicaciones tienda Windows, aplicaciones de Windows Phone y otros, implementando tu lógica del cliente con librerías portátiles .NET grandemente simplificará la creación de múltiples experiencias en múltiples plataformas.
• Moderniza tu experiencia de usuario. Conceptos que demandan usuarios de hoy pueden ser implementados con las últimas innovaciones en .NET para el escritorio. Principios de diseño tales como “rápido y fluido”, “auténticamente digital” y “haz más con menos” pueden ser aplicados para tus aplicaciones de escritorio existentes empleando una interfáz de usuario moderna para el diseño XAML, utilizando cuidadosamente animaciones e implementando .NET programación asíncrona extensivamente.
• Mueve la lógica del negocio al servidor. Aplicaciones de 2-capas (cliente/servidor) son significativamente difíciles de extender a nuevos dispositivos. La forma recomendada es separar claramente la lógica del negocio en servicios que pueden ser reutilizados posteriormente en otros dispositivos y plataformas.
• Extiende a la nube. Una vez separado del cliente, Windows Azure provee múltiples soluciones para mover la lógica del negocio a la nube. Transformando esa lógica en servicios de nube mejora grandemente la elasticidad y escalabilidad de soluciones existentes, alistándolas para abrazar múltiples dispositivos.

.NET en Android e iOS

Microsoft está trabajando con muchos socios para ayudar en el esfuerzo de modernización. Aquí es lo que ello tienen que decir:

• Xamarin provee maneras de compartir código C# de tus aplicaciones que apuntan a Windows o Windows Phone con dispositivos iOS y Android. Provee acceso a la API para crear vistas personalizadas mientras reutilizando el código de lógica del cliente entre dispositivos.
• ITR-Mobility iFactr y MonoCross ofrecen una solución para construir aplicaciones móviles empresariales en C# para entrega en la mayor parte de plataformas móviles. Provee servicios tales como Abstract UI y Enterprise Data Synchronization para permitir aplicaciones de negocios cruzando un rango de dispositivos.
• Mobilize.NET por Art in Soft provee soluciones y servicios para migrar aplicaciones de legado a plataformas modernas incluyendo la web, móvil y la nube, lo hace transformando el código existente en código nuevo sin “runtimes” para la aplicación generada
• Citrix Mobile SDK para aplicaciones Windows provee un rico kit de herramientas para desarrolladores, permite movilizar aplicaciones Windows línea de negocio (LOB) o escribir nuevas aplicaciones táctiles ejecutándose en servidores centrales (Citrix XenApp/XenDesktop) y accedidas desde cualquier dispositivo móvil como Citrix Receiver

Nota: El hecho de que Microsoft está activamente promoviendo Xamarin y MonoCross debería finalmente poner a descanzar los rumores de que Microsoft intenta hacer una demanda legal a los creadores de Mono.}

Guía para aplicaciones de negocios grandes, de misión crítica.

Cuando se trata de grandes compañías y sus aplicaciones de misión crítica el enfoque cambia de costo y productividad a administración de complejidad y calidad de servicio. Estas guías no se refieren a aplicaciones CRUD u orientadas a datos, los desarrolladores trabajando en esas deberían utilizar la guía para negocios pequeños/medianos. Estas guías son para sistemas con muchas partes interconectadas y sub-sistemas con variadas cantidades de independencia.

Aplicaciones Web en la empresa.

Microsoft es inequívoco sobre este punto, para sitios web de misión crítica deberías utilizar ASP.NET MVC. La única cuestión de arquitectura es si es que va a tener una capa de patrones de diseño aplicación de una sola página (SPA) encima.

Otras tecnologías web tales como Web Forms o Web Pages no deberían ser utilizadas. Simplemente no ofrece el control y testeabilidad que tiene MVC, lo cual además limita la calidad de servicio que puede ser obtenida.

Aplicaciones de Escritorio en la Empresa

Como con aplicaciones pequeñas, Microsoft está incluyendo WPF y WinForms en su lista de recomendados. A esto ellos agregan C++ con Win32 o MFC. El uso de C++ es recomendado para proyectos muy grandes, a largo plazo comparables en escala a Microsoft Office. Uno presume que ellos están pensando sobre la diferencia entre AutoCAD y Paint.NET en términos de escala.

Tienda Windows/Windows Phone en la empresa

Rudamente las últimas 20 páginas de la guía, Microsoft pone a parte la discusión de productos y gira su atención a patrones y prácticas.

Inversión de Control.

Microsoft gasta una sorprendente cantidad de tiempo discutiendo inyección de dependencias y contenedores de inversión de control. Ellos listan 9 separados contenedores de inversión de control, la mayoría de los cuales son proyectos administrados por la comunidad sin afiliación con Microsoft. Debe tener en cuenta que muchos de los marcos de desarrollo que están en la lista no son actualmente contenedores IoC (inversión de control) en vez de marcos de injección de dependencia.

La confusión entre los dos continúa toda la sección sin una clara indicación si Microsoft prefiere raíces compuestas (un patrón DI “dependency inyection”) o ubicador de servicios (un patrón contenedor IoC “inversion of control”). Ellos dicen SRP (Single Responsibility Principle) puede resultar en clases que podrían, por ejemplo, tener 15 dependencias listadas en su constructor. Para desconectar estas dependencias ellos sugieren que sean removidas del constructor y en vez de eso sean inyectadas usando un contenedor de inversión de control.

Microsoft también menciona utilizar programación orientada a aspecto (Aspect Oriented Programming) que agregue otra capa de indirección y poder inyectar dependencias.

Bounded Context y Administración de Complejidad

Para controlar la complejidad, Microsoft gasta unas cuantas páginas discutiendo el concepto de un “bounded context”. Está basado en el trabajo de Eric Evans, la idea básica es aislar las aplicaciones en pequeñas partes que compartan de manera limitada. En el ejemplo de abajo hay 4 pilas separadas con diferentes back ends y un interfáz de usuario común.

Su recomendación en esta área tiene mucho sentido. Para “bounded contexts” que identifiques como misión crítica puedes usar el más patrón más caro “Command and Query Responsability Separation” (CQRS) o Domain Driven Design (DDD) con pruebas totalmente automatizadas. Mientras “bounded contexts” auxiliares puede utilizar una arquitectura CRUD ligera. Código de legado obtendrá su propio silo donde puede ser aislado y lentamente reemplazado.

Comunicación y Anti-corrupción.

Para compartir información entre “bounded contexts” Microsoft recomienda utilizar mensajería asíncrona donde sea posible. Esto permite que cada silo trabaje de manera independiente aún cuando otros silos fallan. Para escenarios simples, named pipes y Microsoft Message Queues son opciones fáciles mientras para sistemas complejos se necesita un bus de servicio. Microsoft menciona el Windows Server Service Bus, Windows Azure Service Bus y NServiceBus sin ninguna preferencia.

Cualquier servicio expuesto por un “bounded context” debería ser protegido por una capa anti-corrupción. Parecido a como el chequeo de parámetros protege funciones públicas, una capa anti-corrupción de un “bounded context” protege la data interna de mensajes malformados. Esta capa verifica los mensajes entrantes, ejecuta traducciones necesarias y asgura que los datos malos no sean procesados y almacenados. Esto puede hacerse utilizando código normal .NET pero para escenarios complejos con muchas reglas de negocios cambiantes, Microsoft recomienda una máquina de reglas y plataforma de integración tal como BizTalk.

Mitigando Código de Legado.

El primer paso para tratar con código legado es crear una fachada (facade) sobre él. Esta fachada debería utilizar técnicas modernas tales como caches persistentes, escalables y ocultar patrones que el código antiguo utilice. Con el tiempo el código legado será reemplazado y las fachadas redirigidas a la nuevas capas de servicio.

Conclusiones.

Microsoft está respaldando todo lo que sea nativo, web y marcos de comunicación para .NET excepto Silverlight en el navegador y .NET Remoting. Ellos también recomiendan C++ y JavaScript en varios escenarios. Viejas plataformas tales como VB 6 y clásico ASP ya no son mencionados para que las compañías que todavía los utilicen migren a nuevas tecnologías tan pronto como sea posible.

Esperen ver un continuado énfasis en inyección de dependencia, especialmente con ASP.NET MVC y Entity Framework. BizTalk del que se pensó que era una tecnología muerta, está viendo nueva vida con las compañías que tratan de integrar arquitecturas en sus instalaciones y en la nube.

ASP.NET MVC 2: Quince cuestiones que deberías conocer

lunes, 3 de mayo de 2010

15

En marzo de 2008 publiqué un megapost en el que se recogían respuestas a diez preguntas básicas sobre el framework ASP.NET MVC, que por aquellos entonces se encontraba todavía en una versión muy preliminar, la Preview 2.

Más de un año después, coincidiendo con el lanzamiento de la versión 1.0, actualicé el contenido y las preguntas conforme a la evolución de los desarrollos y a lo que había podido profundizar en el tema desde entonces, en el post ASP.NET MVC: Trece preguntas básicas.

Y de nuevo en 2010, continuando lo que ya parece que es una tradición, aprovecho el reciente lanzamiento de ASP.NET MVC 2 para actualizar las respuestas y añadir algunas nuevas cuestiones básicas que pienso pueden resultar de interés a desarrolladores que todavía no conocen este nuevo marco de trabajo de Microsoft.

Trataré de responder a las siguientes preguntas:

1. Empecemos desde el principio, ¿qué es MVC?
2. ¿Qué ventajas tiene el uso del patrón MVC?
3. ¿Qué es ASP.NET MVC framework?
4. Espera… pero entonces, ¿programar con ASP.NET MVC no consiste en usar Webforms, pero separando los componentes en capas?
5. ¿Es el primer framework MVC creado para .NET?
6. Como desarrollador de aplicaciones web con ASP.NET, ¿me afectará la llegada de este framework?
7. Entonces, ¿no significa la aparición del framework MVC la muerte próxima de los Webforms de ASP.NET?
8. Pero… ¿Vale la pena pasarse a ASP.NET MVC o sigo usando Webforms?
9. Pero siempre que leo algo sobre MVC viene rodeado de un gran número de conceptos extraños como IoC o DI. ¿Es que ASP.NET MVC es sólo para gurús?
10. ¿Puedo convertir mi proyecto ASP.NET Webforms a ASP.NET MVC?
11. ¿Se puede utilizar Ajax con el framework MVC?
12. ¿Se puede utilizar VB.NET con ASP.NET MVC?
13. ¿Puedo usar LINQ desarrollando aplicaciones con ASP.NET MVC framework?
14. ¿Qué tipo de tecnologías puedo utilizar en las vistas?
15. ¿Es ASP.NET MVC framework software libre?

El post es un poco extenso, así que mejor que os pongáis cómodos… ;-)

1. Empecemos desde el principio, ¿qué es MVC?

Aunque de forma algo simplista, podríamos definir MVC como un patrón arquitectural que describe una forma de desarrollar aplicaciones software separando los componentes en tres grupos (o capas):

• El Modelo que contiene una representación de los datos que maneja el sistema, su lógica de negocio, y sus mecanismos de persistencia.
• La Vista, o interfaz de usuario, que compone la información que se envía al cliente y los mecanismos interacción con éste.
• El Controlador, que actúa como intermediario entre el Modelo y la Vista, gestionando el flujo de información entre ellos y las transformaciones para adaptar los datos a las necesidades de cada uno.

MVC son las siglas de Modelo-Vista-Controlador, y se trata de un modelo muy maduro y que ha demostrado su validez a lo largo de los años en todo tipo de aplicaciones, y sobre multitud de lenguajes y plataformas de desarrollo. Puedes encontrar más información en:

• Wikipedia, Modelo-Vista-Controlador
• Documentos originales de definición de MVC, de Trygve M. H. Reenskaug, en Xerox (¡año 1978!) 
• Tutorial de Java, Arquitectura MVC
• Model-View-Controller Web presentation pattern en MSDN

2. ¿Qué ventajas tiene el uso del patrón MVC?

Como siempre esto de enumerar ventajas es algo subjetivo, por lo que puede que pienses que falta o sobra alguna (¡dímelo!). En un primer asalto podríamos aportar las siguientes:

• Clara separación de responsabilidades entre interfaz, lógica de negocio y de control, que además provoca parte de las ventajas siguientes.
• Facilidad para la realización de pruebas unitarias de los componentes, así como de aplicar desarrollo guiado por pruebas (TDD).
• Simplicidad en el desarrollo y mantenimiento de los sistemas.
• Reutilización de los componentes.
• Facilidad para desarrollar prototipos rápidos.
• Sencillez para crear distintas representaciones de los mismos datos.
• Los sistemas son muy eficientes, y a la postre más escalables.

Pero bueno, también se pueden citar algunos inconvenientes:

• Tener que ceñirse a una estructura predefinida, lo que a veces puede incrementar la complejidad del proyecto. De hecho, hay problemas que son más difíciles de resolver, o al menos cuestan algo más de trabajo, respetando el patrón MVC.
• Al principio puede cierto esfuerzo adaptarse a esta filosofía, sobre todo a desarrolladores acostumbrados a otros modelos más cercanos al escritorio, como Webforms.
• La distribución de componentes obliga a crear y mantener un mayor número de ficheros.

3. ¿Qué es ASP.NET MVC Framework?

Es un framework, un marco de trabajo cuya segunda versión acaba de ver la luz, que ha sido creado por Microsoft con objeto de ayudarnos a desarrollar aplicaciones que sigan la filosofía MVC sobre ASP.NET.

Además del conjunto de librerías (ensamblados) que proporcionan las nuevas funcionalidades a nivel de API, incluye plantillas y herramientas que se integran en Visual Studio 2008 y 2010 (tanto en sus versiones Express como en sus hermanas mayores) para facilitarnos un poco las cosas.

Visual Studio 2010 ya incorpora ASP.NET MVC 2 de serie, mientras que en la versión 2008 es necesario descargar e instalar el software (puedes hacerlo con el Web Platform Installer u obteniéndolo desde el sitio de Microsoft).

En cualquier caso, una vez montado, Visual Studio mostrará un nuevo tipo de proyecto (ASP.NET MVC 2 Web Application) que nos permitirá crear el esqueleto básico de un proyecto de este tipo.

Y ya para cuando estemos en faena, el entorno ofrece multitud de utilidades para hacer nuestro trabajo más fácil, como la herramienta de creación de vistas automáticas, el desplazamiento entre controladores y vistas, o plantillas para la definición de controladores, entre otras.

4. Espera… pero entonces, ¿programar con ASP.NET MVC no consiste en usar Webforms, pero separando los componentes en capas?

No. ASP.NET MVC es una forma de crear aplicaciones para la web basadas en ASP.NET de una forma radicalmente distinta a los formularios web, para que te hagas una idea:

• no existe el postback,
• no hay viewstate,
• no hay eventos,
• el diseñador visual deja de tener sentido,
• como consecuencia no hay controles de servidor, al menos en la forma en que los conocemos,
• no es necesario utilizar los archivos code-behind de las páginas .aspx,
• las páginas no siguen complejos ciclos de vida; de hecho, el proceso de una petición es infinitamente más simple que en Webforms,
• nosotros controlamos totalmente el código de marcado generado,
• también tenemos control absoluto sobre las URLs de acceso a nuestra aplicación; ahora, con ASP.NET 4 también es posible con Webforms, pero en versiones anteriores (y todavía actuales como .NET 3.5) no era tarea fácil,
• podemos sustituir componentes internos del framework para adaptarlo a nuestras preferencias,
• basa muchos aspectos en el concepto convención sobre configuración, tan satisfactoriamente utilizado en otros entornos,
• se integra con Ajax de forma natural, sin artificios como los UpdatePanels y similares,
• favorece la introducción de buenas prácticas como la inversión de control o inyección de dependencias,

… y un largo etcétera. Realmente, ASP.NET MVC es una tecnología muy distinta y que requiere que los desarrolladores tengamos que acostumbrarnos a pensar de otra manera y dedicar tiempo a aprenderla para sacarle partido.

Sin embargo, el hecho de que el framework esté creado sobre ASP.NET hace que no tengamos que partir de cero: muchos de los conocimientos que ya tenemos seguirán siendo válidos y aplicables en este nuevo contexto.

5. ¿Es el primer framework MVC creado para .NET?

No, ni el único. Existen multitud de frameworks MVC para ASP.Net, como MonoRail, Maverick.Net, FubuMVC y muchos otros.

6. Como desarrollador de aplicaciones web con ASP.NET, ¿me afectará la llegada de este framework?

No necesariamente. Puedes seguir desarrollando aplicaciones como hasta ahora, con Webforms. Si así lo decides, este nuevo framework no te afectará nada; simplemente, ignóralo.

De todas formas, ya que has leído hasta aquí, permíteme un consejo: aprende a utilizar ASP.NET MVC framework. Después podrás decidir con conocimiento de causa si te conviene o no.

7. Entonces, ¿no significa la aparición del framework MVC la muerte próxima de los Webforms de ASP.NET?

En absoluto. Son simplemente dos filosofías diferentes para conseguir lo mismo, ¡páginas web!

La tecnología de Webforms es muy útil para asemejar el desarrollo de aplicaciones web a las de escritorio, ocultando la complejidad derivada del entorno desconectado y stateless (sin conservación de estado) del protocolo HTTP a base de complejos roundtrips, postbacks yviewstates, lo que nos permite crear de forma muy productiva formularios impresionantes y que el funcionamiento de nuestra aplicación esté guiado por eventos, como si estuviéramos programando Winforms.

Sin embargo, esta misma potencia a veces hace que las páginas sean pesadas y difícilmente mantenibles, además de dificultar enormemente la realización de pruebas automatizadas. Y por no hablar de comportamientos extraños cuando intentamos intervenir en el ciclo de vida de las páginas, por ejemplo para la carga y descarga de controles dinámicos.

ASP.NET MVC propone una forma distinta de trabajar, más cercana a la realidad del protocolo y, curiosamente, más parecida a cómo se hacía unos años atrás, cuando controlábamos cada byte que se enviaba al cliente o se recibía de éste. No existen, por tanto, conceptos como el mantenimiento del estado en el viewstate, ni elpostback, ni nos valdrán los controles de servidor basados en estas características, que en la práctica son la mayoría.

Sin embargo, dado que el framework está creado sobre ASP.NET, será posible utilizar páginas maestras, codificar las vistas en un .aspx utilizando C# o VB.NET, usar los mecanismos de seguridad internos, control de caché, gestión de sesiones, localización, etc.

8. Pero… ¿vale la pena pasarse a ASP.NET MVC o sigo usando Webforms?

En mi opinión, no se trata de decidirse por una u otra tecnología, sino de conocer ambas y utilizar la más apropiada en cada momento. Hay muchos aspectos a tener en cuenta, como:

• los conocimientos y experiencia del equipo de desarrollo
• la necesidad de usar controles o sistemas preexistentes
• la madurez del framework
• el futuro de la tecnología
• la importancia de ventajas propias de MVC
• el tipo de sistema que se pretende construir

Vamos a reflexionar sobre cada uno de estos puntos, y la decisión os la dejo a vosotros. ;-)

Conocimientos y experiencia del equipo de desarrollo

La tecnología de formularios web (Webforms) permite el desarrollo rápido de aplicaciones (RAD) a través de diseñadores visuales con los que es posible componer una página compleja y definir el comportamiento del interfaz a golpe de ratón, puesto que el framework se encarga de realizar parte del trabajo duro, como el mantenimiento del estado entre peticiones, convertir propiedades de controles en código HTML y CSS, o incluso generar scripts que realicen determinadas tareas en cliente.

De hecho, siguiendo este modelo es posible crear aplicaciones para Internet sin tener apenas idea de las particularidades inherentes al desarrollo web, lo que permite que muchos programadores procedentes del mundo del escritorio puedan ser productivos muy rápidamente, aunque sea a costa de generar páginas mucho más pesadas y con un código de marcado complejo.

No hay que olvidar que para determinado tipo de aplicaciones, los Webforms son una buena opción, tanto como lo han sido hasta ahora. Por tanto, si el equipo de desarrollo tiene ya experiencia creando aplicaciones con esta tecnología y no posee grandes conocimientos sobre programación web de más bajo nivel ni experiencia previa trabajando con el patrón MVC, deberíamos ser prudentes antes de dar el salto a ASP.NET MVC, puesto que la productividad, al menos inicialmente, va a caer.

“Un gran poder conlleva una
gran responsabilidad”

-- El tío Ben, a Peter Parker

ASP.NET MVC requiere un conocimiento más profundo del entorno web y sus tecnologías subyacentes, puesto que a la vez que ofrece un control mucho más riguroso sobre los datos que se envían y reciben desde el cliente, exige una mayor responsabilidad por parte del desarrollador, ya que deberá encargarse él mismo de mantener el estado entre peticiones, maquetar las vistas, crear las hojas de estilo apropiadas, e incluso los scripts.

Esto, sin embargo, no difiere mucho de la forma de trabajar unos años atrás, y es posible que en el equipo de trabajo haya desarrolladores experimentados que se sientan incluso más cómodos trabajando a este nivel que utilizando abstracciones como las provistas por ASP.NET Webforms.

Necesidad de utilizar controles o sistemas preexistentes

Otro aspecto a valorar antes de dar el salto a ASP.NET MVC es que existe una altísima probabilidad de que no podamos utilizar porciones de código o componentes visuales que hayamos desarrollado previamente, lo cual redundará en los tiempos de desarrollo y productividad del equipo de trabajo.

No nos valdrán los controles de servidor, ni las plantillas de proyectos, ni los generadores de código, y en muchos casos ni siquiera la herencia de editor (que por muy antipatrón que sea seguro que acostumbramos a utilizar).

Sin embargo, y aunque en volumen no es aún comparable a Webforms, cada día existen más componentes para ASP.NET MVC de compañías dedicadas a la creación de herramientas de programación, y generados desde la propia comunidad de desarrolladores, que nos ayudan a ser más productivos.

También hay que tener en cuenta el encaje tan sencillo del framework MVC con soluciones basadas en cliente, como jQuery y su interminable colección de plugins, en los que podemos encontrar elementos de interfaz para prácticamente cualquier necesidad.

Madurez del framework

Aunque en sus principios la adopción de ASP.NET MVC framework podía suponer ciertos riesgos debidos a su escasa madurez, hoy en día ya no es así.

Gracias a la disponibilidad del código fuente y su relativa simplicidad interna, los errores que pudieran detectarse en él podrían ser rápidamente subsanados.

La madurez también se hace patente en la cantidad y calidad de información disponible. ASP.NET MVC, aunque cuenta con una comunidad de desarrolladores bastante entusiasta, son una minoría comparándola con su veterana competencia, y sobre todo en el mundo de habla hispana.

Lo mismo ocurre con el número ingente de componentes y controles reutilizables disponibles para Webforms. Dado que no son compatibles con el framework MVC, se parte de una situación de clara desventaja frente a éstos, aunque como comentaba anteriormente, esto está ya cambiando y seguro que con el tiempo seguirá a mejor.

Consideraciones sobre el futuro de la tecnología

Si lo que te preocupa es el futuro de los Webforms, has de saber que Microsoft va a seguir dándoles soporte y mejorándolos, como no podía ser de otra forma. Por tanto, de momento no es necesario que bases tu decisión en esto.

Eso sí, hay quien opina que ASP.NET MVC será el estándar de creación de sistemas web en unos años, por lo que en cualquier caso se trata de una tecnología que no habría que perder de vista…

Beneficios de ASP.NET MVC

Las ventajas de la arquitectura MVC, descritas anteriormente, y las bondades del diseño del framework son un buen aliciente para comenzar a trabajar con ASP.NET MVC.

De hecho, deberíamos tener muy en cuenta en qué aspectos nuestros desarrollos van a beneficiarse del uso de esta tecnología y valorar si estas ventajas compensan los inconvenientes que su adopción va a suponer:

• la separación de aspectos impuesta por el patrón MVC obligará a tener un código más limpio y estructurado, independizando totalmente la interfaz de la lógica de navegación y, por supuesto, de la de negocio.
• de la misma forma, esta división facilita el trabajo en equipo, pues permite el avance en paralelo en las distintas capas.
• si entre nuestras prioridades está el asegurar el correcto funcionamiento de nuestros componentes a través de pruebas unitarias, o hemos optado por utilizar una metodología de desarrollo guiado por pruebas (TDD), ASP.NET MVC nos vendrá de perlas. La separación de aspectos citada anteriormente facilita la creación de pruebas específicas para los componentes de cada capa de forma independiente, así como el uso de técnicas avanzadas (mocking, inyección de dependencias…) para que éstas sean lo más completas posible.
• las friendly URLS, o direcciones amigables, es un beneficio directo del uso del framework de Microsoft. Estrictamente hablando no es mérito de la plataforma MVC, sino del juego de clases presentes en el espacio de nombres System.Web.Routing, incluidas en .NET framework 3.5, pero en cualquier caso si optamos por esta tecnología la tendremos “de serie”, con las ventajas que ello conlleva (SEO, REST, claridad en direcciones…).
• al final, el software será mucho más mantenible; el hecho de que los componentes estén separados y bien estructurados simplificará las tareas de mantenimiento.
• el conjunto de convenciones en cuanto a la estructura de proyectos y de nombrado y disposición de elementos facilitará el desarrollo una vez sean asimiladas.

El tipo de sistema

A la hora de plantearse un cambio de este tipo es imprescindible tener en cuenta el tipo de proyecto en el que vamos a trabajar.

No es lo mismo desarrollar un sitio web colaborativo destinado a un gran número de usuarios, como Facebook o Digg, donde el control fino sobre la entrada y salida es crucial para asegurar aspectos como la escalabilidad, cumplimiento de estándares, o accesibilidad, que crear una aplicación de gestión que utilizarán un grupo relativamente reducido de usuarios desde una intranet corporativa.

En ambos casos se trata de crear sistemas web, pero los objetivos, requisitos y restricciones a considerar son muy diferentes.

Para el primer caso, ASP.NET MVC es una magnífica opción. La simplicidad de la arquitectura MVC hace que elciclo de vida de las páginas de este framework sea mucho más sencillo que el de los Webforms, y la ausencia de automatismos y persistencia de estado aligera en gran medida el peso y complejidad de las páginas, lo cual redundará muy positivamente en el rendimiento del sistema.

Si además el proyecto requiere o resulta beneficiado por el uso de direcciones URL amigables (por razones de SEO, para presentar un interfaz claro de tipo REST, o cualquier otro motivo), más aún, aunque su diferencia respecto a Webforms se ha reducido ligeramente con la aparición de ASP.NET 4.

Por último, la facilidad de introducción de funcionalidades Ajax hacen de ASP.NET MVC una opción muy apropiada para estos sistemas con estilo “2.0”. Un ejemplo de aplicación real de este tipo es la famosa comunidad StackOverflow.

En cambio, el segundo caso, cuando se trata de crear pesadas aplicaciones de gestión con interfaces de usuario complejos y en las que no es especialmente relevante la calidad del código HTML enviado al cliente, ni el peso de éstas al ser entornos cerrados y controlados, ASP.NET Webforms sigue siendo una opción razonable.

Las facilidades para el desarrollo rápido de aplicaciones (RAD) son mayores utilizando formularios web, aunque sea a cambio de sacrificar aspectos como la separación de código e interfaz, o la facilidad para realización de pruebas unitarias.

9. Pero siempre que leo algo sobre MVC viene rodeado de un gran número de conceptos extraños como IoC o DI. ¿Es que ASP.NET MVC es sólo para gurús?

No, ni mucho menos. De hecho, el funcionamiento de ASP.NET MVC es en muchos aspectos bastante más sencillo que la tecnología Webforms a la que estamos habituados.

Esos términos que tan frecuentemente encontramos en posts y artículos son técnicas y patrones que podemos utilizar para mejorar la calidad de nuestras aplicaciones o extender el framework, y estrictamente hablando no tienen nada que ver con ASP.NET MVC.

Por ejemplo, la Inyección de Dependencias (DI, Dependency Injection) es una técnica que permite realizar aplicaciones cuyos componentes se encuentran muy desacoplados entre sí, lo que flexibilizar el diseño y, por ejemplo, facilita la realización de pruebas unitarias. Se trata de un patrón muy fácilmente implementable y que nos puede aportar muchos beneficios.

La inversión de control (IoC, Inversion of Control), relacionada con el concepto anterior, permite modificar en determinadas circunstancias el flujo de ejecución, cediendo la responsabilidad de realizar tareas específicas a componentes especializados externos a nuestra aplicación. El caso más típico es el uso de software IoC (llamados contenedores) para delegar a ellos la instanciación de clases, lo que permite modificar la implementación concreta de la clase de forma externa, siempre que se cumpla un contrato (normalmente, un interfaz).

También es habitual encontrar referencias a técnicas para facilitar las pruebas unitarias, como la construcción de mocks, stubs, o fakes, que conceptualmente no son más que objetos falsos cuyo comportamiento y datos preconfiguramos explícitamente para poder probar de forma más sencilla nuestros métodos.

Como puedes comprobar, se trata de tecnologías ajenas a ASP.NET MVC, pero dado que las ventajas del patrón y el buen diseño del framework favorecen la utilización de buenas prácticas como el testeo unitario, o la inyección de dependencias, conocerlas nos vendrá de perlas.

Y en cualquier caso, son conceptos son muy sencillos y fácilmente asimilables, pues responden a necesidades con las que seguro que todos hemos encontrado, aunque en su momento no conociéramos su nombre.

10. ¿Puedo convertir mi proyecto ASP.NET Webforms a ASP.NET MVC?

Sí, pero tardarás un buen rato ;-)

Al menos que conozca, no existe ninguna herramienta ni siquiera capaz de intentar realizar tal proeza.

Hay que tener en cuenta que aunque en ambos casos se trate de aplicaciones web sobre ASP.NET, el cambio de una a otra tecnología no es una mera traducción como podría ser convertir una aplicación VB.NET a C#; se trata de un nuevo marco de trabajo que afecta sobre todo a la presentación y control de flujo del sistema.

Si tienes unas buenas clases de lógica de negocio, bien aisladas de la tecnología Webforms (como debería ser, por otra parte), probablemente sean los únicos componentes que puedas reutilizar de forma directa y sin grandes cambios.

El resto, es decir, todo lo relativo a la interacción con el usuario y la lógica de control y navegación, habría que convertirlo de forma manual, y por tanto, probablemente habría que pensarse bien si vale la pena hacerlo. Por esta razón es más habitual plantear MVC como plataforma para aplicaciones de nuevo desarrollo.

11. ¿Se puede utilizar Ajax con el framework MVC?

Absolutamente. De hecho, ASP.NET MVC se lleva de fábula con librerías de scripting como las incluidas en el framework ASP.NET 3.5 SP1, 4.0, o, lo que es mejor, con la inigualable jQuery.

La limpieza de la filosofía MVC hace posible que sea realmente sencillo realizar desde cliente llamadas a los controladores mediante scripting con objeto de obtener datos, actualizar porciones de contenido de la página con el marcado de la vista correspondiente, o, en definitiva, interactuar con el servidor.

En este mismo blog puedes encontrar multitud de ejemplos de integración de jQuery y ASP.NET MVC, que aunque implementados con las previews del framework (¡a ver si un día tengo un rato y los voy actualizando!), pueden ayudarte a entender cómo hacerlo.

Otro aspecto interesante respecto a jQuery es que esta librería entró a formar parte de la plataforma de desarrollo de Microsoft hace tiempo, lo que en la práctica aporta varias ventajas:

• jQuery y algunos de sus plugins vienen incluidos de serie en las plantillas de proyectos ASP.NET MVC, facilitando su uso desde nuestras aplicaciones;
• asimismo, se encuentran también disponibles en las CDN de Microsoft para agilizar su distribución
• se ha realizado un esfuerzo importante por mejorar la integración con Visual Studio de esta librería, facilitando archivos que hacen posible el disfrute de intellisense mientras la utilizamos,
• asegura más que nunca la apuesta a jQuery como framework de implementación en cliente, al contar con el respaldo del gigante MS.

Ahora bien, dado que el framework MVC no permite el uso de controles de servidor runat="server" (al menos como veníamos haciéndolo, pues han dejado de existir aspectos tan fundamentales para ellos como elviewstate o los postbacks), vas a tener que despedirte de soluciones Ajax para Webforms como el célebreUpdatePanel o los controles del ASP.NET Ajax Control Toolkit. Pero créeme, no las echarás de menos ;-)

12. ¿Se puede utilizar VB.NET con ASP.NET MVC?

Por supuesto. Aunque la mayoría de código que se encuentra por la red utiliza C#, probablemente porque es el lenguaje en el que ha sido desarrollado y sobre el que se están exponiendo más ejemplos desde las previews más tempranas del producto, cualquier lenguaje .NET podría ser utilizado sin problema para desarrollar aplicaciones sobre este framework.

A nivel de entorno de desarrollo, Visual Basic ofrece el mismo nivel de ayudas y plantillas que C#, pero desconozco si esto es así en otros lenguajes.

13. ¿Qué tipo de tecnologías puedo usar para implementar el Modelo?

Curiosamente, una de las cosas sobre el Modelo que más llamó la atención al aparecer el framework MVC fue precisamente la ausencia de directrices o indicaciones sobre cómo debía implementarse éste. De hecho, la carpeta /Models, utilizada por convención para almacenar los componentes de esta capa, venía vacía en la versión 1.0 del producto.

La explicación, sin embargo, era bien sencilla: ASP.NET MVC es completamente independiente de del Modelo, es el desarrollador el que elige cómo implementarlo siembre que se respeten los límites impuestos por el patrón MVC.

Teniendo en cuenta las responsabilidades del Modelo, habitualmente encontraremos en esta capa:

• entidades de negocio,
• clases de lógica empresarial, que implementan los procesos y reglas de negocio,
• mecanismos de acceso a datos, por ejemplo usando directamente las clases de ADO.NET, o mejor aún, un ORM que nos aísle de la persistencia, como Linq2Sql, Entity framework o el veterano NHibernate.

14. ¿Qué tipo de tecnologías puedo utilizar en las vistas?

El objetivo de las vistas es componer el interfaz de usuario y los mecanismos de interacción con el usuario. Lo habitual, por tanto, será utilizar algún lenguaje de marcado, como XHTML ó HTML, CSS y Javascript, aderezado con bloques de código de servidor que se ejecutará en el momento de renderizar la página.

También puedes utilizar la tecnología Ajax para enviar u obtener información desde el servidor, siempre mediante llamadas a acciones definidas en el controlador, que te permitirán crear interfaces más dinámicos y actuales.

Pero sobre todo, nada de utilizar controles de servidor (Label, Button, Dropdowns…). Estos deberán ser sustituidos por sus elementos (X)HTML equivalentes, lo que implica que perderemos los automatismos provistos por Webforms para el mantenimiento del estado de los controles.

<for each="var name in names">
  <test if="name == 'Jose'">
    <p>Yo mismo</p>
    <else/>
    <p>Amigo: ${name}  
  </test>
</for>

Otra posibilidad interesante que aprovecha y demuestra la flexibilidad de la arquitectura de ASP.NET MVC framework, es la utilización de motores de vistas distintos al estándar.

Existen multitud de motores ligeros (NHaml, Spark, Brail, NVelocity…), cada uno con su propio lenguaje de marcas y convenciones, que permiten la definición de vistas a partir de plantillas como la que se muestra en el lateral (ejemplo de Spark).

15. ¿Es ASP.NET MVC framework software libre?

Pues sí, ASP.NET MVC Framework es software libre. A primeros de abril de 2009 se comenzó a distribuir oficialmente el código fuente de ASP.NET MVC con licencia MS-PL (Microsoft Public License), un modelo de licencia aprobado por la OSI (Open Source Initiative) que permite el uso del software en aplicaciones comerciales y no comerciales.

Esto, entre otras ventajas, supuso la rápida adopción del framework MVC en las plataformas .NET alternativas, como el célebre proyecto Mono, con el que es totalmente compatible. Incluso MonoDevelop dispone de herramientas y ayudas específicas para aplicaciones ASP.NET MVC.

El código fuente de ASP.NET MVC se publica en Codeplex, prácticamente de forma simultánea a las distintas revisiones que son lanzadas.

Reflexiones de futuro para un programador .NET

Desde al menos 2008, Redmond está llevando con la lengua afuera a todos los “informáticos” que trabajan sobre sus tecnologías con novedades continuas e importantes en los productos de su gigantesco ecosistema.

Especialmente a los desarrolladores. Ya que, no solamente la evolución ha sido constante en las herramientas, sino que aún han sido más vertiginosas en las posibilidades y capacidades de los diferentes lenguajes de programación que se han ido añadiendo a la plataforma .NET.

Pero eso es historia, y hoy quiero hacer una reflexión sobre el futuro laboral más probable para los millones de programadores que estamos haciendo aplicaciones informáticas diariamente en nuestro trabajo, o como hobby.

C# vs el resto de los lenguajes

Aunque nadie lo quiera reconocer, C# es el que corta el bacalao en los lenguajes de .NET. A continuación yo pondría a C++, pero realmente no es .NET y además es un lenguaje para programadores de “pelo en pecho”.

Mi muy querido Visual Basic .NET, el lenguaje original sobre el que aprendí a programar después de mi larga etapa de Pascal, se sigue utilizando. Pero no es el piloto número uno de la escudería. Y tiene toda la pinta que va a seguir en un lento y muy largo declive.

Otra cosa que no se quiere reconocer es que C# es un Java. Eso sí, ya nació mejorado y vitaminado en relación a su padre no biológico. Pero es que con el tiempo se ha convertido en un lenguaje mucho más robusto, flexible y con un ritmo de evolución demoledor. Tecnologías como Linq, NUnit, MSTest,WCF, programación paralela, programación asíncrona y muchas más cosas han dejado muy atrás al antiguo Java, al cual su compra por Oracle no la ha venido nada bien.

En resumen, .NET es una plataforma de programación con un horizonte lejano y, en su última versión 5.0, sigue manteniendo el mismo ritmo incansable de evolución. Aumentando el nivel de productividad que le hace ser muy rentable para ser utilizado en desarrollos profesionales.

Pero no solamente de C# vive .NET y, en una política excelente, se ha implementado en la plataformamás de 50 lenguajes de programación diferentes. Y entre ellos destacar Pyhton, Ruby, Pascal, PHP, etc.

Visual Studio 2012

Pero en estos tiempos que nos ha tocado vivir, la programación se está convirtiendo en una verdadera ingeniería por su riqueza y complejidad. Ya no vale con escribir líneas numeradas yhacer Goto.

Ahora hay que saber y entender la programación orientada a objetos, el uso adecuado de los interfaces, implementar patrones de programación y arquitectónicos, asimilar conceptos comoInversión de Dependencias y seguir principios como SOLID.

Y, por ello los IDE para trabajar en .NET, se han convertido en herramientas imprescindibles. En mi opinión, ya no son tanto herramientas como parte del propio lenguaje. Me sería, literalmente, imposible ser mínimamente productivo en la construcción de una aplicación Web si no tuviera un Visual Studio en donde desarrollar.

El equipo de Visual Studio es muy consciente de todo ello. Y el que son una de las piedras angulares sobre las cuales la comunidad de desarrolladores .NET pervive. Por eso, y con los recursos que tiene a su disposición, han publicado la versión Preview, ahora RC, de Visual Studio 2012.

El cual no solamente es el IDE más sofisticado y potente que tenemos para desarrollar en cualquiera de las tecnologías Microsoft, si no que es parte integrante de un sistema completo y complejo de gestión del ciclo de vida del software que me permite, desde un solo punto, cubrir las necesidades de todos los puestos y roles relacionados con el desarrollo de un producto informático: diseñador, testeador, programador, BI, DB, arquitecto, gestor, gerente, director, cliente, etc.

Y el presente indica que el futuro sigue el mismo camino. Una nueva versión cada 2 o 3 años, con revisiones y actualizaciones constantes entre estos periodos. Vamos, que no nos vamos a aburrir ni quedarnos anclados en un temible “agujero negro” tecnológico.

Windows 8

Las opiniones sobre el nuevo sistema operativo de Microsoft son múltiples y variadas. Pero todos coinciden en que es una revolución y una apuesta.

Para los desarrolladores y las empresas es como agua de mayo por varias razones.

Podemos seguir construyendo nuestras aplicaciones de escritorio, que cada vez tienen menos volumen, que no importancia. Al igual que podemos seguir construyendo nuestras aplicaciones Web. En esto no cambia prácticamente nada.

Pero se abre un nuevo horizonte al que podremos acceder con nuestros conocimientos actuales: las aplicaciones Metro. Y que además está al alcance para los dos perfiles principales de programadores de .NET: los de escritorio y los de Web. Ya que las aplicaciones para las Tablet Windows 8 (aunque lo corras en tu PC es obvio que es un interfaz pensado para gestos) se pueden realizar en XAML + C# o en HTML5 y WinJS.

Es decir, un mercado nuevo. Al que yo puedo acceder, con suficientes conocimientos de base para empezar a programar de forma inmediata. Y, además, con la ventaja de que he tenido acceso a toneladas de información ANTES de que el producto sea publicado.

Y, como dice bien un compañero, no olvidemos que estamos hablando de un target inicial de 700 millones de dispositivos que ahora mismo tienen Windows. Vamos, vamos, que me froto las manos con el futuro que se ha abierto para los “informáticos” .NET. O sea, para todo el sector.

Incluso va a volver la posibilidad de ir de vaquero solitario por la vida y tener la oportunidad de hacer aplicaciones yo solito e intentar sacarme unas perrillas con ello, o ser el siguiente “Angry Birds”.

Otras plataformas

Pero en .NET, no solo de aplicaciones Web o de escritorio vivimos. Tenemos otras plataformas que no se andan a la zaga en evolución y futuro brillante. Y que son nichos más pequeños pero potentes para los programadores.

Por ejemplo, desarrollo de SharePoint. En la versión 2007 éramos los programadores “apestados”. Como un parche sin mucha relevancia. En el 2010 ya estábamos integrados en el Visual Studio de forma completa, y dejó de ser una mera plataforma a empezar a ser un ecosistema. Con el inminente 2013, los programadores de SharePoint tendrán una productividad y capacidad de desarrollo realmente potente. Integración de Comunicaciones Unificadas, desarrollo en y para la Nube, uso del .NET 4.5, etc.

Otros que están demostrando un potencial tremendo son los desarrolladores en Kinect. Lo que iba a ser solamente un interfaz para juegos de la Xbox, se está utilizando en los proyectos más singulares e insospechados. Con un fuerte componente social en movilidad, superación de minusvalías, educaciones especiales, telepresencia, virtualidad, etc.

Y eso que aún está muy verde todo el tema de la interacción por lenguaje hablado (como un Siri, pero más bestia) que está en pañales y que es un campo más de desarrollo profesional.

También, y siguiendo centrado en el futuro de los programadores en plataforma .NET, la reciente presentación de Windows Phone 8, el sistema operativo para móviles, nos trajo la sorpresa de que va a compartir el core de WinRT con Windows 8. Eso significa que un programador XAML + C#, o C++ va a poder construir, ahora sí, aplicaciones Metro que funcionen casi de forma automática en la Tabletas y en los móviles.

Por último, y que no debemos de olvidar, todo el potencial de la programación en Azure, programación en la Nube. Crear aplicaciones que puedan escalar de forma sencilla y natural. Ajustar los precios a lo que consumimos y poder utilizar una plataforma “infinita” para construir aplicaciones.