Tres punto cinco...
... y una pequeña corrección a los comentarios: será .NET 3.5.
Ese es el número de versión que aparece en la beta de Orcas (vaya nombrecito): el Visual Studio 2007, por llamarlo de algún modo. Lo cierto es que toda esta complicación es culpa de la propia Microsoft, que ha tenido que hacer filigranas con las fechas de salida del Windows Vista y el número de versión de .NET para esa familia de productos.
De todos modos, que no cunda el pánico: .NET 3.0 tiene novedades interesantes, pero ninguna que afecte "profundamente" al desarrollo de bases de datos. Al menos, ninguna que empuje a los renuentes a saltar al carro. Mi consejo es el obvio: hay que ser prudentes con la adopción de WFC. No porque tenga algún problema, sino por tratarse de una novedad ligada a una versión específica del sistema operativo (no es exactamente así, pero para abreviar...).
También sería buena la prudencia respecto a LINQ, el nuevo ADO.NET Entity Framework y esas cosas, aunque por motivos diferentes. La adopción de estas nuevas técnicas no está limitada por la base de instalaciones de un sistema operativo: afectan solamente al programador, y si funcionan bien, nada impide que salte al vagón. Mi impresión, de momento, es positiva... pero repito, hay que ser prudentes. Puede que esta vez estemos frente a la técnica que domestique, de una vez por todas, los famosos "persistency frameworks", pero me asusta ver a gente que tenía por sensata (no, no estoy regañando a ninguno de nosotros) quemar tanto incienso por las extensiones al lenguaje inspiradas por la programación funcional.
El problema consiste en que, para que toda esta historia funcione, no basta con que Anders Hejlsberg sea un monstruo de los lenguajes: hace falta que el equipo completo que tiene que escribir las clases de soporte para tiempo de ejecución haga bien las cosas. Y aunque, repito, creo que todo va a salir bien y que va a ser un producto estupendo, no puedo olvidar que la idea de los "Object Spaces" ha estado dando tumbos desorientada por todo el campus de Microsoft hasta que Hejlsberg y compañía se han atrevido a agarrar el toro por los cuernos.
Ideas para superar el famoso "impedance mismatch" existen desde que se inventó la palabreja de marras. Suelen parecer ideas sencillas y, por lo mismo, geniales... pero hasta ahora, el monstruo que pretenden matar goza de buena salud. Es muy probable, diría que casi seguro, que esta vez sea la definitiva. Pero le aconsejo que no contenga la respiración hasta entonces...
Ese es el número de versión que aparece en la beta de Orcas (vaya nombrecito): el Visual Studio 2007, por llamarlo de algún modo. Lo cierto es que toda esta complicación es culpa de la propia Microsoft, que ha tenido que hacer filigranas con las fechas de salida del Windows Vista y el número de versión de .NET para esa familia de productos.
De todos modos, que no cunda el pánico: .NET 3.0 tiene novedades interesantes, pero ninguna que afecte "profundamente" al desarrollo de bases de datos. Al menos, ninguna que empuje a los renuentes a saltar al carro. Mi consejo es el obvio: hay que ser prudentes con la adopción de WFC. No porque tenga algún problema, sino por tratarse de una novedad ligada a una versión específica del sistema operativo (no es exactamente así, pero para abreviar...).
También sería buena la prudencia respecto a LINQ, el nuevo ADO.NET Entity Framework y esas cosas, aunque por motivos diferentes. La adopción de estas nuevas técnicas no está limitada por la base de instalaciones de un sistema operativo: afectan solamente al programador, y si funcionan bien, nada impide que salte al vagón. Mi impresión, de momento, es positiva... pero repito, hay que ser prudentes. Puede que esta vez estemos frente a la técnica que domestique, de una vez por todas, los famosos "persistency frameworks", pero me asusta ver a gente que tenía por sensata (no, no estoy regañando a ninguno de nosotros) quemar tanto incienso por las extensiones al lenguaje inspiradas por la programación funcional.
El problema consiste en que, para que toda esta historia funcione, no basta con que Anders Hejlsberg sea un monstruo de los lenguajes: hace falta que el equipo completo que tiene que escribir las clases de soporte para tiempo de ejecución haga bien las cosas. Y aunque, repito, creo que todo va a salir bien y que va a ser un producto estupendo, no puedo olvidar que la idea de los "Object Spaces" ha estado dando tumbos desorientada por todo el campus de Microsoft hasta que Hejlsberg y compañía se han atrevido a agarrar el toro por los cuernos.
Ideas para superar el famoso "impedance mismatch" existen desde que se inventó la palabreja de marras. Suelen parecer ideas sencillas y, por lo mismo, geniales... pero hasta ahora, el monstruo que pretenden matar goza de buena salud. Es muy probable, diría que casi seguro, que esta vez sea la definitiva. Pero le aconsejo que no contenga la respiración hasta entonces...
Etiquetas: .NET
Ian Marteens, 12:23 p. m.
3 Comments:
Algunos expertos en bases de datos llevan muchos muchos años diciendo que la forma evidente de acabar con el "impedance mismatch" consiste en integrar las construcciones relacionales en los lenguajes de programación de aplicaciones. Cosa que LINQ no hace del todo bien, y además tiene una sintaxis espantosa. Al final no es mucho más que el viejo SQL empotrado (Embedded SQL).
Habrá que ver que tal funciona cuando se le de caña de verdad.
La duda que tengo es: ¿Será LINQ el final de ADO.NET?
Es que yo veo el problema al revés: el "mismatch" es una bendición más que un incordio.
Y no es por decir algo extravagante: la "orientación a objetos" es muy ineficiente para trabajar en sistemas distribuidos. La culpa la tiene el concepto de identidad, más que la propia idea de división modular de la OOP. Si no fuese por esta razón, hace años que la gente estaría trabajando con Poet, O2 y familia.
Dicho en otras palabras: si descartamos las aplicaciones de bolsillo como "la churrería de mi tía" o "mis pelis preferidas", un único paradigma no es suficiente para aplicaciones de bases de datos. Y el "impedance mismatch" habría ayudado, de manera involuntaria, a mantener ambos mundos separados... hasta ahora.
Casi todo el mundo entiende lo del "mismatch" como lo engorroso que es trabajar con un SGBD SQL desde una aplicación OO. Esto de bendición tiene poco.
La "orientación a objetos" es muy primitiva para trabajar con datos, a mi no se me ocurriría usar únicamente el "paradigma" procedimental ni para la churrería de mi tía.
Si pudiese utilizar el "paradigma" declarativo para todo pues sería lo ideal, pero casi nunca se puede.
La razón por la que Poet, O2 y esos engendros han fracasado miserablemente es por que no son más que arcaicos sistemas de red con un poco de maquillaje OO.
Publicar un comentario
<< Home