• Save
Patrones de arquitectura Software(Capa de Datos)
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Patrones de arquitectura Software(Capa de Datos)

on

  • 13,253 views

 

Statistics

Views

Total Views
13,253
Views on SlideShare
13,253
Embed Views
0

Actions

Likes
8
Downloads
3
Comments
1

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • bueno
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Patrones de arquitectura Software(Capa de Datos) Presentation Transcript

  • 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(); }
  • 5. PATRONES DE SOFTWARE
    “Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, para describir después el núcleo Definición de la solución a ese problema, de tal manera que esa
    solución pueda ser usada más de un millón de veces sin hacerlo siquiera dos veces de la misma forma”.
    • Para que solucionar problemas que otros han resuelto?
    • 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.
  • 10. PATRONES DE SOFTWARE
    Ventajasfundamentales:
    • Están ya probados: son soluciones que han sido utilizadas con anterioridad de manera
    repetida y se ha comprobado que funcionan.
    • Son reutilizables: corresponden con problemas que no son específicos de un caso
    concreto, sino que se presentan una y otra vez en distintas aplicaciones.
    • Son expresivos: cuando un equipo de desarrolladores tiene un vocabulario común de
    patrones, se puede comunicar de manera fluida y precisa las ideas fundamentales sobre
    el diseño de una aplicación.
    La experiencia y el sentido común dictarán cuándo son apropiados y cómo utilizarlos.
  • 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.
  • 17. Ventajasdel DAO
    • Cualquier objeto no requiere conocimiento directo del destino final de la información que se manipula.
    • 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)
    • 25. El código es muy eficiente, si el DAO está diseñado para aprovechar las capacidades de base de datos (procedimientos almacenados o funciones, JOINs, etc.)
  • Desventajas DAO
    • Muchas veces es necesario acceder a datos que estan ubicados en diferentes Repositorio de datos. En mucho de ellos es necesario tener en la cuenta las diferentes particularidades.
    • 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
    • 28. Escribir código para navegar por el modelo de objetos requiere una cierta comprensión del esquema de base de datos
  • Data transfer object (DTO)
    Cuando se trabaja con arquitecturas de varias capas, un problema típico es cómo pasar los datos de
    una capa a otra.
    Conocidos anteriormente como ValueObjects
    Definición http://en.wikipedia.org/wiki/Data_Transfer_Object
    Este tipo de objetos suelen ser lightWeight y de una naturaleza muy simple. No tienen ningún tipo
    de logica de negocio(businesslogic) y son simples contenedores de datos estructurales
    (mapeo orientado a objetos).
    DTO son un tipo de objetos que sirven únicamente para transportar datos
    Un transfer object no es más que un objeto que "empaqueta" datos para que puedan viajar entre
    las capas. Dicho objeto contendrá todos los datos que nos interesen accesibles mediante gettersy
    setters.
    DTO son el concepto principal en el Domain Driven Design (DDD) unametodologia de diseñode
    software.
  • 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)