1. Capa de datos

2. Capa de datos Los APIs de acceso a datos proporciona una capa de abstracción sobre la conexión para los DBMS, normalizando las llamadas de acceso a las base de datos. ADO, ODBC , OLE DB o JDBC, entre varios mas, son APIs(ApplicationProgramming Interface) de bajo nivel para acceder a diferentes fuentes de datos. Esto quiere decir que es un conjunto de objetos y funciones para que los programadores puedan integrar servicios de DBMS dentro de sus aplicaciones. Estos APIs consisten principalmente en un objeto de origen de datos, un objeto de sesión, un objeto de comando y un objeto de conjunto de filas. La secuencia en programación es la siguientes. Inicializar o carga el controlador(driver) del API escogido. Establece la conexión con la fuente de datos. Prepara y envía la sentencia del comando SQL. Ejecuta la consulta, inserción o actulización. Procesar los resultados. Cierra la conexión. El diseño de estos APIs debe tener lo siguiente. 1. Los APIs deben proveer esa estructura de objetos y un mapeo suave al paradigma de "tipos de datos" que ofrecen los DBMS. 2. El programador se debe sentir en contacto directo con el DBMS, no con un socket o un proceso de maquina. 3. La comunicacion al DBMS debe ser facil de programar. 4. Debia ser flexible para aceptar configuraciones diferentes de conectividad. Por consiguiente, la misma aplicación del desarrollador pueda acceder a varios DBMS a la vez.

3. Capa de datos Para cargar una estructura de datos(DataSet), es necesario un objeto que adapte los datos desde la fuente hasta la aplicación. Éste objeto será un DbDataAdapter. El DbDataAdapter, sin embargo, necesita saber qué ejecutar. Para ello hará uso de una orden de base de datos o DbCommand. El DbCommand necesita también cierta información: una sentencia SQL o nombre de procedimiento almacenado para pasarle a la fuente de datos… y una conexión por la cual establecer el intercambio de datos. Esta conexión será un objeto de tipo DbConnection. Por último, el DbConnection únicamente hará uso de una cadena de conexión para establecer el enlace entre aplicación y fuente de datos.

4. Capa de datos usingSystem.Data; //Driver para postgresql usingNpgsql; stringsentenciaSQL = "SELECT * FROM v_personas WHERE numeroDocumento = :doc "; Datasetds; try { // Creamos una conexión a partir de la ConnectionString NpgsqlConnectionconexion = new NpgsqlConnection("Server=127.0.0.1;Port=5432;User Id=postgres;Password=elPassdePsgreSQL;Database=practica2;"); //Abrimos conexión conexion.Open(); // Instanciamos un SqlCommand que ejecutará la sentencia que le pasemos como parámetro con la conexión. NpgsqlCommand personas = new NpgsqlCommand(sentenciaSQL, conexion); //Configuramos el SqlCommand,indicando que ejecutará una sentencia e inyectándole los parámetros personas.Parameters.Add(new NpgsqlParameter("doc", NpgsqlDbType.Text)); // Finalmente, instanciamos un DataAdaptery efectuamos la consulta NpgsqlDataAdapter da = new NpgsqlDataAdapter(personas); da.Fill(ds); } catch (Exception ex) { throw (ex); } finally {conexion.Close(); }

6. Si alguien ya lo resolvió, Cómo comunicar experiencias? Cómo comunicar diseños?

7. Todos tenemos ideas diferentes de un mismo concepto.

8. Emplear un lenguaje que sea comprensible por los desarrolladores, diseñadores, arquitectos.

9. Los patrones de software permiten establecer un lenguaje común para expresar y Motivación comunicar experiencias, diseños y buenas prácticas.En el desarrollo de software de casi todas las aplicaciones es necesario solucionar una y otra vez los mismos problemas: autentificación del cliente, persistencia de datos, separación entre presentación, lógica y control,... En lugar de reinventar continuamente la rueda, es mucho más productivo aplicar estrategias que ya hayan funcionado con anterioridad. Esta idea es la que lleva a la definición de los patrones software.

11. Patrón DAO Data Access Object Objeto de acceso a datos(DAO) DAO es un método muy simple de mapear objetos a bases de datos. Para generar un DAO un desarrollador podría escribir una clase que contiene un atributo para cada campo en la tabla de clientes, y una clase clienteDao que contiene los métodos para la inserción, actualización, selección y eliminación de filas. La clase clienteDao normalmente contienen código con sentencias SQL. Similar al patrón Fowler’sTable Data Gateway utilizado a menudo con el patrón DTO. Es un componente de software que suministra una interfaz común entre la aplicación y uno o más repositorios de datos. Es una solución al problema del diferencial de impedancia (ImpedanceMismatch) entre una aplicación orientado a objetos y una base de datos relacional. Utiliza únicamente la interfaz de programación (API) nativa de el manejador de bases de datos, o algún otro sustituto como el OBDC,DBI, JDBC, OLEDdb entre otros.

12. DAO Data Access Object El patron DAO se utiliza para: Abstrae y encapsular los accesos a los datos. Gestiona las conexiones a los repositorios. Obtiene o actualiza los datos almacenados en los repositorios.

13. Estructura del DAO Data Access Object BusinessObject: Es el objeto que quiere acceder a la fuente de datos para poder almacenar o consultar datos. DataAccessObject: Abstrae al BusinessObject de los detalles del acceso a la fuente de datos. DataSource: Representa la implementación de la fuente de datos en sí. Transfer Object: es un objeto intermedio entre el BusinessObject y el DataAcessObject

14. Ejemplo DAO Se tiene la siguiente tabla en un motor relacional. CREATE TABLE ciudades ( nombre varchar (80), departamento varchar(80)); Se crean dos clases para cada relación con la que en nuestra aplicación tendrá acceso: el acceso a datos y el transporte de datos Clase de acceso a datos: PublicclassCiudadesDAO { Ciudad ciudad; .... //establece la conexion a la base de datos //implementa operaciones basicas como insert,update, delete voidinsert() {....} voiddelete() {....} voidupdate() {....} Ciudad find() { ....SELECT * FROM ciudades WHERE nombre.....} } Clase transporte de datos: Publicclass Ciudad { //atributos = campos de la relación string nombre; string departamento; //metodos StringgetNombre() {....} StringgetDepartamento() {....} }

15. DAO Data Access Object Sin embargo como las aplicaciones del mundo real no están compuestas por el acceso a una simple tabla, para enfrentar esta situación se utiliza el patrón Factory que permite implementar una fábrica de objetos DAO. En General (aunque esto es una decisión de diseño), por cada objeto de negocio en nuestro sistema, se de crear un DAO distinto. La información que devuelve o se le pasa al DAO se en cápsula en objetos de tipo TRANSFER OBJECT(objeto de tranferencia), que, simplificando, dos o más que "contenedores de información".

16. DAO Data Access Object RELACION CON OTROS PATRONES El DAO se relacionan comúnmente con los siguientes patrones: Transfer object(DTO): la información que se envía/recibe del DAO se "empaqueta« en estos objetos. Factory: con el objeto de conseguir la independencia del almacén de datos, comúnmente se usan este patrón para instancias los DAOs.

18. Se baja el nivel de acoplamiento entre clases, reduciendo la complejidad de realizar cambios.

19. Se aísla las conexiones a la fuente de datos en una capa fácilmente identificable y mantenimiento.

20. Se oculta los detalles de implementación a la fuente de datos.

21. Simple - puede ser entendido por la mayoría de los desarrolladores .

22. Separación de los datos (DTO) y el comportamiento (DAO).

23. Diseñado para arquitecturas distribuidas (clases DTO se puede pasar entre las capas y clases DAO pueden ser expuestos como servicios WEB).

24. No requiere tiempo de ejecución de contenedores (código DAO puede ser una unidad de prueba en el cliente)

26. El repositorio no tiene porqué proporcionar un API común. Las aplicaciones deben poder acceder de forma transparente a estos repositorio.

27. Requiere grandes volúmenes de código (se puede utilizar un generador de código DAO

29. Data transfer object (DTO)

30. una interfaz es estructura de datos que muestra únicamente las firmas de los métodos de una clase. Por consiguiente, una clase que herede de la interfaz se obliga a implementar el como realizara la implementación de dichos métodos(acciones). Esta interfaz únicamente dice QUÉ acciones se van a realizar, pero no CÓMO se realizarán. Definición del patrón AbstractFactory: http://es.wikipedia.org/wiki/Abstract_Factory_(patr%C3%B3n_de_dise%C3%B1o) Generalmente un proyecto de software se desarrolla con una fuente de datos en particular (PostgreSQL,SQL Server, MySQL, Firebird, Oracle, Archivos XML,archivos de excel, archivos de texto,cvs…). Sin embargo, la fuente de datos podría cambiar en cualquier momento, por lo que se debería, en la medida de lo posible, abstraer el desarrollo de la aplicación de la fuente de datos. AbstractFactory (Factoría Abstracta)

31. AbstractFactory (Factoría Abstracta)