Siempre recordaré cuando jugábamos de pequeños, en todos los grupos siempre había un «listillo» o «aventajado» que cuando estábamos en plena partida siempre se inventaba alguna nueva regla o norma para intentar ganar, eso siempre nos obligaba a hacer cambios en nuestras estrategias, para intentar ser el ganador del juego.
Algo parecido me ha pasado desde que trabajo con datos, primero con los recordsets de VB y ahora con los datasets y datatables del Visual Studio .net; es decir, siempre accediendo a los datos de las consultas a través de cadenas de texto, pero claro siempre hay un «listillo», en estos casos los administradores de bases de datos o los jefes o cualquier persona con poder suficiente para decirte: «bien ahora que tienes el campo Codigo de la tabla clientes que seguro que usas en 3 sitios muy concretos, se va a llamar Id_Cliente, así que en 1 hora estará todo cambiado, así que venga a por ello». Tu como buen, rápido y eficiente empleado ctrl + h o replace «Codigo» por «Id_cliente», justo cuando lo vas a hacer cumpliendo plazos (te sientes el rey del mundo), te das cuenta de que «mierda a quien se le ocurriría poner como campo principal de la tabla proveedores Codigo también», mi gozo en un pozo, ahora toca revisar todos los códigos y ver donde se puede cambiar. Tras las 8 horas de rigor llega el jefe y te pregunta: «Que ya acabaste eso?, si es un cambio sencillo, se hace de 2 patadas», y tu acordándote de la persona que le cambio los pañales.
Seguro que esta situación la hemos vivido, la vivimos y la viviremos muchos desarrolladores en nuestro dia a día.
Una forma que hace tiempo «descubrí» se trata de un pequeño truquito, que gracias al EDM averiguamos, es, crear un enumerador por cada tabla de la BBDD con todos los campos de la misma, entonces cuando queremos acceder a un campo tenemos que hacer algo como:
String field = dTable.Rows[0][Clientes.Codigo.ToString()].ToString() //Accedemos al valor de la fila 0, de la columna código de un datatable
Si ya tenemos una clase con los datos de las columnas (segun el modelo de aplicacion que usamos en Maldivas) , podemos insertar un enumerador que se llame por ejemplo Fields y que contenga lo de antes. Esto tiene una pega y es que los que useis FxCop os dara un warning en la definición de la clase por tener el enumerador dentro de la clase, entonces nos quedaria así:
String field = dTable.Rows[0][Clientes.Fields.Codigo.ToString()].ToString()
Con esto podemos estar preparados para cuando llegue el malvado administrador de base de datos o tu jefe y diga: «Cambia el campo», y con un simple refactoring del enumerador, tendríamos en todos los sitios del programa nuestro campo cambiado.
Ahora llega el momento de los «menos trabajadores» que estarán pensando, ya pero claro yo que tengo 1000 tablas de 1000 campos cada una, tengo que mantener eso….¡¡¡INMANTENIBLE!!! Para eso tenemos una herramienta que se llama CodeDom, desde la cual se puede generar código simplemente leyendo información de la base de datos, generando el fichero de código a través de los datos obtenidos de las columnas.
Otra ventaja que tenemos con este metodo es que tenemos un «intellisense» para poder acceder de forma facil a los campos que queremos que contenga la fila.
Otra forma de resolver este metodo es creando constantes de tipo string y con el nombre del campo como valor de la constate. Esto tiene algunos problemas, mucho lio, muchas variables, y que perdemos ese intellisense que con el otro caso tendríamos.
Espero que os sea de utilidad y si conoceis otros metodos que sirvan para resolver este tema, me encantaria comentarlo con vosotros.