Benditos TableAdapter

Recuerdo la primera vez (y no tan primera), en la que empecé a trabajar con aplicaciones cliente-servidor, donde el cliente realizaba consultas a la base de datos. En concreto fue una aplicación en un entorno WAMP (Windows-Apache-MySQL-PHP). En aquel momento el problema de realizar consultas se realizaba de manera algo rudimentaria, vamos, la select a piñón en el código, mezclado además entre el propio diseño de la página, y poquito más. La cosa fue mejorando cuando a partir de alguna pequeña técnica y concatenando strings la cosa tomaba mejor forma. Eso sí­, el gran salto vino cuando conocí­ cómo resolver el problema a través de clases de manejo de SQL, las cuales te ayudaban a realizar selects, updates, inserts y deletes, abstrayéndote un poco de lo que es el SQL en sí­. Es más, realmente podí­as hacer una consulta en una base de datos sin tener ni idea de qué era el SQL.
A medida que pasó el tiempo, y con algo más de experiencia, apareció la necesidad clara de relacionar las interacciones contra la base de datos directamente con cada uno de los objetos del modelo de negocio. Es decir, ya no sólo crear las consultas ayudado por una jerarquí­a de objetos, si no que dichas consultas tuvieran sólo sentido embebidas en las clases que te ayudaban a gestionar el negocio. Ejemplo simple: cuando tengo que realizar una select que me retorna todos los usuarios de mi aplicación, voy a utilizar métodos de mi propia clase de Usuarios que son los que van a tener incorporados por debajo las clases de interacción con la base de datos.
Normalmente se puede hacer una relación 1 a 1 entre las tablas de base de datos maestras de una aplicación y las clases (hablando en términos de programación orientada a objetos). Qué bonito serí­a, pensaba yo, que cada vez que creo una tabla en mi base de datos, inmediatamente tuviera un objeto que me ayudara a manejarla. Poder acceder directamente a los campos, conocer su tamaño, su tipo, poder añadir métodos para realizar inserts, updates, selects… Es más, era algo que preparaba manualmente. Creaba la tabla, luego un objeto para manejarla, donde cada campo de la tabla era una propiedad de la clase, creaba métodos para realizar inserts, selects… Vamos, para mi una maravilla, era algo laborioso, pero a mi parecer bastante elegante.
Qué bonito, seguí­a pensando yo, que llegue un momento que este se pudiera crear automáticamente. Y… entonces salió Visual Studio 2005 y los TableAdapter. Madre mia, alguien habí­a escuchado mis plegarias y habí­a hecho exactamente lo que necesitaba. La verdad es que hací­a ya tiempo que conocí­a la existencia de los TableAdapter, pero hasta hace poco no habí­a tenido la ocasión de trabajar directamente con ellos.
Soy totalmente conocedor de que aíºn me queda bastante tiempo para dominarlos, pero por lo que conozco ahora, realmente me parecen una auténtica maravilla. Para quien desee conocerlos, dejo un link, https://msdn2.microsoft.com/es-es/library/bz9tthwx(VS.80).aspx
Saludos a todos!

3 thoughts on “Benditos TableAdapter”

  1. Hola, he leido por ahi (pero aun no tengo afirmación cierta), que cuando las base de datos son grandes (imaginemos una aplicacion como mercado libre ) los tableadapter se vuelven mas lento , que si escribimos nuestras propias clases, tal como lo hacias antes.
    me gustarí­a saber tu opinión al respecto,
    saludos y gracias !

  2. Hola Cristian,
    Indudablemente es una solución más lenta en ejecución. Segíºn el escenario donde tengas que desarrollar tu solución, esta podrá ser una herramienta adecuada o no. Está claro que si uno de los requerimientos principales de tu escenario es el tiempo de respuesta, ésta no es la mejor herramienta que puedas elegir.
    Saludos.
    Miguel.

  3. Estimado Miguel, muchisimas gracias por tu pronta respuesta, y realmente este post es muy bueno!.
    saludos y seguiré leyendote
    Cristian.-

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.