El titulo que ilustra esta entrada estaba pensado para una publicación del 1ero. de Abril, sin embargo . . . no es una broma :).
Recientemente me he involucrado en un proyecto utilizando Microsoft .NET, plataforma que hasta hace poco he driblado con maestría ya que Microsoft siempre ha sido enemigo explicito del Software Libre (o del Open Source, nuevo termino favorito de este blog).
Como bien dijera Mercedes Sosa «cambia, todo cambia» y a finales del 2014 Microsoft abrió el código de .NET, con lo cual por fin (desde mi punto de vista) vale la pena dedicarle alguna linea en este blog.
Diferente de Java y los lenguajes de la JVM, mis experiencias previas con .NET han sido mayoritariamente en el ámbito académico (como estudiante y profesor) además de trabajos a nivel comercial con .NET Micro Framework (aka .NET para ARM/Windows CE), por lo que este post fue escrito como «JVM Developer experimentando .NET para desarrollo web luego de 3 años». Así, condenso en este post algunas de mis impresiones, sorpresas y decepciones con la plataforma luego de varias semanas de usarla a nivel comercial.
NuGet (sorpresa agradable)
Con la creación de CodePlex y a pesar de los malos augurios, Microsoft ha logrado construir un ecosistema alrededor de su plataforma, cosa que Delphi no logro ni en sus sueños más salvajes.
Para muchos programadores de otras plataformas no suena muy coherente crear cosas para una plataforma cerrada (yo incluido), sin embargo NuGet se ha nutrido de bastante código libre incluso antes de la liberación de .NET y hoy por hoy es un administrador de dependencias interesante.
La sintaxis de dependencias para NuGet es bastante más simple que los POM de Maven y se asemeja más a los archivos usados por NPM (conceptualmente pero no sintacticamente), además de esto Visual Studio incluye «Package Manager» para un abordaje totalmente imperativo al descargar dependencias.
Hay que tomar en cuenta que Maven ademas de ser un gestor de dependencias es un Task Runner y que Graddle ha ganado popularidad en los ultimos años. Uno de sus puntos negativos es que (y a diferencia de Maven) no se pueden mantener dependencias de un paquete en diferentes versiones y diferentes ramas (por ejemplo tener en una rama de desarrollo Entity Framework 5 y en otra Entity Framework 6), intentarlo solo lleva a problemas de compilación por dependencias nativas y proyectos que van quedando sucios..
Como anecdota de NuGet uno de nuestros programadores más jóvenes no creía que antes la gente pagaba (y pagaba caro) por los discos de la documentación de .NET y bibliotecas auxiliares.
Licencia verdaderamente libre (lo más brutal de .NET)
Cuando liberaron .NET sentí literalmente que el infierno se congelo, y fue un orgasmo darme cuenta que la licencia utilizada para esto no es otra sino la altamente liberal MIT. Esto contrasta con la menos liberal GPL utilizada por Java. La verdad hay que decirla y en este ámbito (y a pesar de liberar solo una parte) la liberación de .NET ha sido su «característica más brutal«.
Visual Studio 2013 (Meh. . .)
Diferente de los Java IDEs, por excelencia en .NET solo hay dos IDE: MonoDevelop y Visual Studio, siendo que el primero esta a bastantes años del segundo.
Junto con la liberación de .NET Microsoft ofrece Visual Studio Community que basicamente es la version Enterprise pero que solo puede ser usado por equipos de 5 desarrolladores. Parecería una comparación injusta pero viniendo de Eclipse y Netbeans, Visual Studio es bastante insípido y afirmo sin pena que le faltan las siguientes cosas:
- Un buen administrador Git, el administrador actual parece un aborto entre Git y TFS. . . como resultado conocí Source Tree.
- Un mejor editor de código, ReSharper cubre esta característica muy bien y en el peor de los casos las Productivity Power Tools cubren algunas de sus falencias.
- Lo que más odio de Visual Studio. En la configuración padrón de Visual Studio hay que detener el servidor IIS para escribir de nuevo código!!! y al usar un navegador externo, el mismo abrirá una pestaña nueva por cada ejecución, toda una pesadilla. Afortunadamente esto si se puede deshabilitar..
Lastimosamente Visual Studio no es libre, por tanto sus problemas no deberían ser abordados por la comunidad.
Programación funcional y LINQ (sorpresa agradable)
La programación funcional es ciudadano de primera clase en .NET ya que C# lo soporta desde antes que Java. Esto se nota especialmente en LINQ, cuando las consultas son pequeñas y directas es más coherente escribir una consulta de datos utilizando expresiones lambda y se siente más Orientado a Objetos (recordando que la Programación Funcional es ortogonal a la Orientada a Objetos).
jOOq también ya se dio cuenta de esto y disponibiliza una versión con soporte para expresiones Lambda, sin embargo aun es muy joven como para hacer una comparación justa.
Frameworks/Bibliotecas (Meh. . .)
.NET se monto en estos últimos años al tren de clientes ricos en html 5, y al igual que los WebJars, en NuGet se pueden encontrar varios proyectos como jquery, angular, react, requirejs con lo cual cubren considerablemente bien esta parte (aunque generan dependencia donde no necesariamente tiene que haberla).
En la parte backend, en NuGet se encuentran cosas interesantes, y entre las bibliotecas que utilizo actualmente tengo las siguientes opiniones:
AutoMapper
Por limitantes del proyecto, algunas partes se cubren con un patrón DTO (sucio pero funcional a mi parecer) Automapper cubre muy bien su objetivo y los mapeos de DTO a entidad son bastante rápidos (de escribir y ejecutar) utilizando expresiones Lambda, es por mucho mi dependencia favorita.
Unity
Diferente de Java, en la oficina creemos que «.NET asume que eres tonto» y la inyección de dependencias es opcional en comparación a Java Enterprise Edition o al mismo Spring.
Sin embargo, para generar proyectos «testeables» y código con cohesión baja, Unity es obligatorio y funciona bien. Solo que requiere una etapa de configuración adicional que no existe en frameworks de tipo «convention over configuration».
Entity Framework
Este ha sido tal vez mi mayor disgusto, Entity Framework se vuelve difícil a menos que se tenga claro el abordaje que puede ser «Code First» o «Database First». JPA es más simple en este sentido o al menos más liberal.
Sin embargo una frase que hará sentido a desarrolladores Java y que resume mi disgusto es que:
«Entity Framework no tiene merge de grafos»
De nuevo (y más correcto)
«Entity Framework no tiene merge de grafos conformados por entidades desconectadas»
Hay un WorkItem en CodePlex acerca de esto planeado junto con la implantación del capitalismo en Corea del Norte. Sin embargo es un atributo imprescindible al crear aplicaciones HTML 5, es inaudito que no se pueda enviar un POST con un grafo padre->hijo completo a una aplicación Stateless (esencial para microservicios), en su modo de funcionamiento normal el desarrollador debe verificar manualmente los cambios en los hijos, es demasiado código.
De acuerdo al mismo item NHibernate cubre bien esta parte, y utilizar Entity Framework en este contexto fue un disparo en el pie que me llevo de vuelta a los inicios de los 2000 (8) If you wanna be my lover (8). Eventualmente solucioné parcialmente esta falencia con GraphDiff.
Mi recomendación es simplemente NO utilizar Entity Framework si la aplicación es un cliente HTML 5 que enviara grafos con padres e hijos (tan común en clientes HTML 5) y si no me creen basta verificar el WorkItem en CodePlex.
Conclusiones
En general el utilizar .NET ha sido una experiencia si no agradable, al menos enriquecedora que me da más elementos/argumentos a la hora de ofrecer soluciones. Espero que Java no tarde demasiado en adoptar Lambdas en JPA, y claro dificilmente dejare la JVM esto si era parte del titulo del 1 de Abril :).
Un efecto secundario de usar .NET es que hay que usar Windows (mi sistema operativo #1 para juegos . . . que considero funcional solo para eso). Siendo asi estas semanas he extrañado:
Cosas que me han gustado de estas semanas
- El ecualizador de AIMP;
- SourceTree;
- Que en el 2015 casi todas las apps que uso sean multiplataforma -e.g. Firefox, Atom, Hexchat, Java-.
