DataAdapter+DataSet vs Ikea

Al tener que acceder a la base de datos para tantas cosas y tantas veces, uno se plantea cual es la forma más eficiente de acceder a ella y sobre todo como puede uno ahorrarse todas esas tareas repetitivas como actualizar, insertar y borrar datos.

Por otra parte no todos los modulos de la aplicación tienen las mismas necesidades asi que se pueden plantear basicamente dos formas de hacer las cosas:

- Una forma más cómoda es utilizar MySqlDataAdapter, DataSet, unos buenos DataBindings y toda la panda, que facilitan la vida cuando se trabaja con formularios asi como las relaciones padre-hijo entre diferentes tablas como Proveedores y ProveedoresTelefono por ejemplo.

El tema esta en definir la logica de insercion, borrado y actualización y practicamente se hace el resto solo.

- La otra forma consite en hacerselo uno mismo todo (Ikea). Es algo mas complejo para ser aplicado a formularios, pero permite un uso mas amplio por otros modulos de la aplicación, además de no tener que aprenderse el ADO.NET.

El ejemplo seria la clase FarmaAuthorize de gestion de usuarios. Diversos módulos definen objetos de este tipo para autentificar, crear y borrar usuarios, todo ello sin tener nada que ver con MySqlCommands y demas en la clase que utiliza el objeto.

El obstaculo viene a la hora de adaptarlo a modulos formulario. Se deben crear metodos que sincronicen lo que aparece en el formulario con la base de datos utilizando las herramientas proporcionadas por la clase intermedia.

Estas son las dos formas que he utilizado y utilizare en el proyecto para los accesos a base de datos. Son algo diferentes en tiempo de programación y velocidad pero se adaptan a las necesidades de cada parte de la aplicacion.

Y esto es todo por hoy…..voy a por ti Parasitologia!!

Examenes y el proyecto

Bueno, en primer lugar lo evidente: hasta que termine los examenes no voy a programar más.

Cuando termine, entonces el proyecto entrara en la recta final, en la que solo queda la programación de ciertos modulos practicamente clónicos (acceso a base de datos con altas, bajas, modificaciones, consultas y busquedas y realmente ya esta hecho), el módulo más importante: el de tasación y por supuesto finalizar el sistema de impresión y el de ayuda en linea.

Pero esto no quiere decir que no pueda sacar algo de tiempo para hacer otras cosas como publicar unas capturas de lo que he hecho hasta ahora que se vea (Forms)  y que funcione:

- Splash de la aplicacion

- Login. Necesaria la autentificacion del usuario previo inicio de la aplicacion

-  Gestion de usuarios de los usuarios de la aplicacion. (El sistema de caducidad esta pendiente de implementacion o puede no ser implementado)

- Modulo clonicos de gestion (en este caso facultativos, pero igual para proveedores, ensayos, pacientes, etc…)

Sobre los niveles de autorización

En un servicio farmacéutico o en una oficina de farmacia trabajan a diario un número considerable de personas dependiendo del servicio que presten.

Este personal desenpeña diferentes roles con diferentes responsabilidades, es decir, un auxiliar no puede tener el mismo nivel de responsabilidad que el licenciado a cargo del servicio. Esta diferenciación no solo esta motivida por el reparto de trabajo, si no por la propia ley que exige que el licenciado firme y autorice la entrada de materia prima, los controles efectuados, las fórmulas elaboradas, etc.

Debido a esto se plantea un problema a la hora de implementar el programa: deben existir múltiples usuarios con diferentes niveles de autorización.

La solución (por lo menos a mi entender) incluye:

- Niveles de autorización completamente configurables e independientes de cada módulo (Facultativos, Pacientes, Control calidad, Materias primas, la propia gestión de usuarios,…)

- Registro completo de todas las acciones realizadas con cada módulo del programa por cada usuario detallando hora, fecha y nivel de autorización utilizado, incluso la acciones no exitosas (necesario si se quiere tener un control de calidad en todo el proceso de elaboración).

- Identificación del usuario al iniciar la aplicación mediante un identificador propio y una contraseña almacenada en la base de datos y “encriptada” (más bien resumida) con MD5. Así se evita que cualquier usuario pueda utilizar la cuenta de otro (al menos parcialmente).

A continuación se incluye un diagrama general del proceso de autorización de un acción para un usuario determinado: