Pablo Castro ADO.NET Entity Framework

La Beta 2 de este producto llamado ADO.NET Entity Framework, permite darnos la idea de las bondades de esta herramienta y a la vez provoca algunas dudas sobre sus limitaciones.

Pablo Castro es uno de los integrantes del equipo que construyo este Add-On.

La version actual que ha sido liberada solo tiene la capacidad de generar el modelo de clases de un producto de software en función del modelo entidad relacion de la base de datos.

En esta version de prueba, no es posible construir manualmente, una a una las clases asociadas a las tablas que uno crea conveniente. Naturalmente en la version final esto sera permitido y otras caracteristicas mas seran liberadas.

El ADO.NET Entity Framework no vendra incluido en la version oficial del Visual Studio 2008, a mediados del proximo año, podra ser descargada para ser usada como un Add-On.

Mientras tanto nos queda la posibilidad de seguir usando el Linq To Sql para facilitar la construccion de clases orientadas a la estructura de una base de datos.

Tiempo de respuesta en OLEDB y ODBC

Hace muchos años atras la people programaba aplicaciones con acceso a base de datos utilizando proveedores genericos como OLEDB y ODBC.

Estos proveedores de acceso a datos por su naturaleza, la de ser genericos, traia como consecuencia un bajo rendimientos en las operaciones. En terminos sencillos, lo generico es lento en contraparte de lo especializado.

Los proveedores como OLEDB y ODBC tienen que enfrentarse a diferentes base de datos como SQL Server, ORACLE, DB2, MS Access, etc. para obtener resultados y realizar operaciones de escritura.

El que mucho abarca poco aprieta, reza un viejo refran.

Felizmente, cada motor de base de datos liberó, posteriormente, sus propios interpretes para facilitar la vida de los developers y mejorar el performance del producto de software que accede a dicho motor de base de datos.

Estos nuevos interpretes estan totalmente especializados para realizar operaciones sobre aquellos motores para los cuales fueron liberados.

Por sentido comun, si estas especializado en algo, eres más rapido y eficiente en realizar operaciones en aquello que sabes hacer.

No arrastremos prejuicios acercar del performance de una aplicación en funcion al tiempo de respuesta de la operacion contra base de datos, cuando se utilizaban proveedores como OLEDB y ODBC.

Decir aquello: "... no hagas SELECT * FROM table, por que es muy lento, usa Stored Procedures...". Ya no tiene asidero, a estas alturas del partido.

Sin embargo en las operaciones de escritura, aun deberia usarse los omnipresentes Stored Procedures, pero como consecuencia de otros argumentos.