ADO,ORM, Entity Framework PDF

Preview

Summary

Los propios apuntes...

Description

ADO.NET Es un conjunto de componentes de software que los programadores pueden usar para acceder y modificar datos de una base de datos en general relacionales. Es la última tecnología de bases de datos de Microsoft que representa una manera eficiente de manipular datos. Es un conjunto de clases que exponen servicios de acceso a datos desde la plataforma .NET. Se diseño para el trabajo con conjuntos de datos tanto conectados como desconectados (reduce el tráfico de red). Existen dos componentes de ADO.NET que se pueden utilizar para obtener acceso a datos y manipularlos: Data provider y DataSets. Las clases data providers son las que proporcionan el acceso a la fuente de datos ( Microsoft SQL Server u Oracle por ejemplo) y tienen clases de utilidad como Connection (que proporciona conectividad a un origen de datos), Command (que permite tener acceso a comandos de bdd para devolver datos, modificar datos, enviar o recuperar info sobre parámetros), Parameter, DataAdapter. Por otro lado, los dataSets están expresamente diseñados para el acceso a datos independientemente del origen de datos. Como resultado, se puede utilizar con múltiples y distintos orígenes de datos, con datos XML o para administrar datos locales de la aplicación.

Dos formas de trabajo: Conectado: Se tiene una conexión permanente con la base de datos, trabajando siempre con los datos actualizados(frescos).

La desventaja se da cuando tengo n consultas por hacer. Tiene peligros en manejo de RAM Desconectado: Consiste en recuperar los datos de base de datos, y trabajar con ellos sin mantener una conexión abierta. Al finalizar la modificación de los datos, estos se pueden actualizar volviendo a establecer una conexión con la fuente de datos. Pasos para trabajar con el escenario desconectado: 1. 2. 3. 4. 5. 6. 7.

Abrir conexión Llenar el DataSet mediante el DataAdapter Cerrar conexión Procesar el DataSet Abrir conexión Actualizar datos mediante DataAdapter Cerrar conexión

ORM (Object Relationship Mapper) Es una técnica que nos permite convertir los tipos de datos de un lenguaje de programación OO a los tipos de datos con los que funciona un sistema gestor de base de datos relacionales. Traduce, cada una de las columnas de una tabla de la bdd se convierte en una propiedad del objeto y viceversa. Los frameworks que la implementan también son conocidos como ORM, (Entity Framework en .Net o Hibernate en Java) Para configurar la relación entre un obj y una tabla de bdd, las ORM utilizan convenciones de nombres, archivos XML o notaciones dentro del código. El uso de una herramienta ORM introduce una capa de abstracción entre el desarrollador y la bdd. Gracias a este mapeo entre el obj y la tabla, el desarrollador no tiene que “escribir a mano” las consultas. Es tarea de la ORM tomar lo que el desarrollador escribe en su lenguaje de programación y convertirlo a una sentencia SQL que el sistema de base de datos acepte. VENTAJAS: Requiere escribir muy poco, no hay que escribir las consultas SQL. Podemos cambiar la bdd con la que estamos trabajando sin impactar en el código de la aplicación.

ENTITY FRAMEWORK Es un ORM en .NET. Nos permite agregar capas de abstracción Es un ORM framework (open-source) para aplicaciones .NET sostenidas por Microsoft. Permite que los desarrolladores trabajen con clases especificas de dominio sin tener que enfocarse en las tablas y columnas donde los datos son guardados. Con Entity Framework, los desarrolladores pueden trabajar a un nivel de abstracción más alto cuando manejan datos y, pueden crear y mantener adata-oriented applications con menos código. Definición oficial: VENTAJAS: Facilidad y velocidad de uso. Abstracción de la bdd usada, seguridad de la capa de acceso a datos. VENTAJAS:

Entity Graph: Antes de llamar al método SaveChanges() debemos identificar los estados de cada entidad en el grafo. Hay diferentes patrones para identificar el estado de una entidad, por ejemplo, el que usa a la Key para identificar el estado: //me fijo si el id es vacio, de ser asi significa que recien lo cree, si no sig que lo modifique

context.Entry(contact).State = contact.Id.Equals(Guid.Empty) ? EntityState.Added : EntityState.Unchanged;

Debemos tener en cuenta a la hora de hacer modificaciones, que los contextos son independientes entre si, y que si por ejemplo: me traigo un

Formas de carga y consultas con EntityFramework Eager loading: Es el proceso por el cual una query para un tipo de entity también carga las entites relacionadas como parte de la query, de esta forma no necesitamos ejecutar una query separada para las entities relacionadas. Eager loading es concebido utilizando el método Include().

Lazy loading: En este caso, los datos relacionados a una entity son traídos en el momento que son requeridos. Es el opueso a eager loading.

Desactivar Lazy loading: Dada una entity o contexto especifico, podemos desactivar el Lazy loading, para ello no hay que hacerla virtual. Para desactivar Lazy loading en todas las entities del contexto, hay que configurar dicha propiedad y ponerla en false:

Reglas para Lazy loading: 1. context.Configuration.ProxyCreationEnabled debería ser True 2. context.Configuration.LazyLoadingEnabled debería ser True 3. Navigation property should be defined as public, virtual. Context will NOT do lazy loading if the property is not defined as virtual.

Explicit loading: Incluso con Lazy Loading desactivado, es posible lazy load las entities relacionadas, pero se lo debe hacer con una llamada explicita. Debemos usar el método Load() para cargar las related enteties explícitamente:

El context.Entry(student).Reference(s => s.StudentAddress).Load() carga el StudentAddress entity. El método Reference() se utiliza para obtener un obj de la propiedad navegable especificada. De la misma manera, el context.Entry(student).Collection(s => s.Courses).Load() carga la propiedad navegable (collection) Courses del Student entity. El metodo Collection() obtiene un obj que representa la collection navigation property. El método Load() ejecuta el SQL query en la bdd para obtener los datos y cargar la referencia especificada o collection property en memoria.

El metodo Reference debe utilizarse cuando una entity tiene una navigation property a otra entity. El metodo Collection debe utilizarse cuando una entity tiene una navigation property to a collection of other entities.

Para cargar las entidades navegables existen 3 formas (enfoques):

Code first: Es un enfoque de Entity Framework que se basa en crear primero las clases en un lenguaje a elegir (C#, VB.NET, etc), crear las relaciones entre las mismas y listo, la bdd la generara EF en base a mis clases de dominio.

La secuencia seria: 1. Creo/ modifico clases de dominio 2. Configuro dichas clases con Fluent-API o data annotation attributes 3. Creo/ actualize la bdd con los migration automaticos o code-base migrations Ejemplo:

Model First: Es un enfoque de Entity Framework que se basa en crear primero las entidades, relaciones, y jerarquías de herencia directamente en el nivel de diseño de EDMX y luego se genera la bdd en base a dichos aspectos. Mediante un diseñador, se genera el modelo de la base de datos (se genera un archivo .edmx). Allí defino entidades, relaciones y herencias que representan mi realidad y a partir de ese modelo de genera la base de datos en código, y el código de mi dominio para manipularla.

Data Base / Design First: Es un enfoque de Entity Framework que se basa en primero diseñar un MER o MR en una especie de Visual designer y de ahí generar las tablas y entidades. Ya se tiene una base de datos existente y a partir del esquema, se genera el modelo (.edmx), el cual puede ser actualizado en cualquier momento en que el esquema cambie. Con el modelo entonces, se genera el modelo de datos.

FLUENT API: Cuando trabajamos con EF Code-First, podemos presentarnos frente a situaciones en las cuales no queremos/ podemos seguir las convenciones basadas en EF y necesitamos mapear entidades de otra manera. Hay dos maneras de configurar EF de forma de no seguir dichas convenciones, annootations ( [Key] ) y Fluent API. Las annotations son como un subconjunto de Fluent API, por lo que hay algunos escenarios de mapeos en los que no se pueden concebir mediante annotations. Fluent API es comúnmente encarado por el lado de overridear el método OnModelCreating en el DbContext. Permite crear tus propias convenciones para sustituir las pre-definidas

Podemos usar un DbModelBuilder y overridear el método OnModelCreating y hacer magias que limpian, tiene funciones que facilitan pila de cosas que si no tendrían que hacerse de manera mucho mas larga. Evita que “decoremos” el código lo cual lo termina ensuciando.

Queda un dominio de estructura de datos , a nivel de propiedades Si tengo public {get;set;} no hay encapsulamiento, validadores, nada, Problema: donde pongo los validadores, lo s termino poniendo en los servicios, y el flujo me muestra que en servicio hago validaciones(lo cual no es su responsability), el dominio queda anémico y tiro a base, no aprovecho el tipo polimórfico tampoco, validar sus datos es responsabilidad de usario,

Tdd para un respositorio, para las op que tenga, si

.

• Entity Graph (Grafo de entidades) de EntityFramework. • Formas de carga y consultas con EntityFramework. Deberán conocer las 3 formas de carga de propiedades navegables, sus nombres y su funcionamiento general....