Notación Húngara: Una convención de .NET y Delphi

Como muchos sabéis, porque lo he comentado por aquí alguna vez, las prácticas del ciclo de FP las hice en una empresa que trabajaba en .NET y allí tuve mi primera experiencia con la llamada Notación Húngara. Esta fue creada por el programador húngaro Charles Simonyi, famoso por haber sido el padre de Bravo (el primer editor WYSIWYG) y uno de los responsables de Micosoft Office.

Aunque en Delphi no acabó de tener éxito, la notación húngara sí ha sido muy utilizada dentro de los desarrollos de la propia Microsoft. Dicha notación consiste en añadir antes del nombre de las variables uno o varios caracteres que indican su tipo. Esta técnica era muy útil hace años, si bien en la actualidad tiene muchos detractores, dado que actualmente es sencillo conocer el tipo de una variable sin tener que leerla en su declaración, por lo que se considera que esta notación sólo añade complejidad a la hora de programar.

Los prefijos a usar más habituales son:

  • a: Array
  • b: Booleano
  • by: Byte
  • c: Caracter de un byte
  • d: Tipo numérico de alta precisión (double o float)
  • dw: Tipo numérico de alta precisión
  • e: Evento o enumeración
  • f: Puede ser función o flags
  • fn: Función
  • g: Tipo delegado
  • h: Puede ser Hashtable o Handle
  • hdc: Handle a un contexto de dispositivo
  • hwnd: Handle a un contexto de ventana
  • i: Entero
  • ID: Identificador
  • l: Entero largo, de 32 bits. También puede ser ‘lock’, para definir objetos de control tipo candado
  • lbl: Objeto label
  • lp: Puntero a entero de 32 bits
  • lpfn: Puntero a una función que devuelve un entero largo
  • lpsz: Puntero a una función que devuelve una cadena terminada en cero
  • n: Entero de 16 bits o tipo enumerado
  • o: Objeto
  • p: Puntero
  • pt: Coordenadas empaquetas en un entero de 32 bits
  • rgb: Valor de color rgb empaquetado en un entero de 32 bits
  • s: Cadena de texto
  • sz: Cadena de texto terminada en cero
  • t: Variable tipo struct
  • txt: Caja de texto
  • v: Variable
  • w: Entero de 16 bits
  • x: Coordenada x.
  • y: Byte. También puede ser una coordenada y.

Otra de las cosas que se achaca a esta nomenclatura es la inexistencia de un estándar claro, lo que puede llevar a confusiones a la hora del mantenimiento del código.

Usando librerías .dll de .NET en SQL-Server2008

Aunque normalmente no se recomiende tener la lógica de negocio en el lado del servidor de la base de datos, en algunos casos puede resultar interesante el hacerlo. Microsoft, en su empeño (por otra parte loable) de lograr una integración total entre sus servicios, nos permite utilizar nuestras .dll creadas en .NET (sea en VB.NET o en C#.NET o en C++) dentro de nuestra base de datos SQL-Server como “código gestionado”.

Iré construyendo poco a poco un ejemplo para que veáis, paso a paso como se realiza esto. Lo primero es activar clr para que nos permita la integración con .NET tal que así:

USE [basedatosdeejemplo]
go
sp_configure 'clr enabled', 1
go
reconfigure
go

Seleccionamos la base de datos a utilizar, configuramos clr como ‘enabled’ (armado, activado) con el parámetro 1 y ejecutamos reconfigure para que el cambio tenga efecto. Acuérdate de poner el parámetro (en este caso 1) y de ejecutar reconfigure.

El primer paso está realizado. Lo siguiente es crear el ensamblado para la librería, definiendo el esquema y el tipo de permisos.


CREATE ASSEMBLY [Utilidades]
AUTHORIZATION [dbo]
FROM 'C:\LibreriaEjemplo.dll'
WITH PERMISSION_SET = SAFE
GO

Creamos el ensamblado con el nombre “Utilidades” (podemos darle el que queramos mientras no sea una palabra reservada), con el esquema dbo (podríamos haber utilizado cualquiera de los disponibles), en FROM le especificamos la dirección del archivo en disco mediante una cadena de texto con la ruta y finalmente los permisos, en este caso SAFE.

SAFE es el permiso más restrictivo que hay, el más “seguro” para nuestro equipo pues limita mucho lo que pueda hacer la librería. En caso de que uses liberías de terceros es el permiso que te reportará más seguridad. Existe también el permiso EXTERNAL_ACCESS, que permite que el código acceda a ciertos recursos externos (registro, archivos, red) y el permiso UNSAFE, que da control sin restricciones a la librería sobre los recursos de la máquina. Si usas una librería propia puedes usar UNSAFE, pero si usas una de un tercero piensa que pueden entrañar riesgos de seguridad.

Con lo puesto ya tenemos la librería disponible en nuestra base datos. ¿Y ahora qué? Ahora simplemente puedes usar las clases y métodos de dicha librería en tu base. Puedes crear tus tipos de datos propios usando sus objetos, incluir sus métodos en procedimientos o triggers. En este ejemplo vamos a suponer que la librería importada tiene una clase Point que guarda las coordenadas de un eje X y un eje Y junto a un valor booleano, y tiene también una función GetCoordsAsText que muestra un mensaje largo con las coordendas. Vamos a crear un tipo de datos Point, usarlo en una tabla, acceder a los valores y usar el método GetCoordsAsText en una función. Pondré comentarios para ir explicando el proceso

--Creamos el tipo de datos Point como un objeto de la clase Point.
--Para acceder a la clase point tenemos que usar el método external name de SQL-Server
--accediendo a la clase mediante el nombre del assembly que creamos antes y el namespace de la clase (en 
--este caso point)
create type Point
external name Utilidades.Point 
go

--Creamos la tabla

create table dbo.Points
(
	id int identity primary key,
	valor Point
);
go

--Para acceder a los datos de la tabla debemos usar un método que nos devuelva
--los valores almacenados dentro del objeto en forma de texto (en este caso .X para el valor X, .Y para 
--el valor Y o .ToString() para sacar ambos en una columna como texto).

select id,
			valor.X as X,
			valor.Y as Y,
			valor.ToString() as Completo
from dbo.Points

--Si intentáramos acceder al objeto a pelo, como voy a poner debajo, nos devolvería el valor del objeto
--sin convertir (un churrazo con la dirección de memoria del puntero)

select valor from dbo.Points --así nos saldría un churo tipo 0x0000000100020000303000000

--También podríamos usar los métodos de la librería en una función, trigger, función de agregado,
--cursor... En este caso haremos una función que acceda a GetCoordsAsText (que está en la clase 
--UserFunctions)

create function dbo.CoordenadasComoTexto
returns nvarchar(50)
as
    external name Utilidades.UserFunctions.GetCoordsAsText

Y con esto tendríais la función que simplemente ejecuta el método definido en la dll y un tipo de datos igual al objeto. Las posibilidades de esto son muy grandes, así que podéis ir profundizando.