Docstoc

ADO Entity Framework - Assembla

Document Sample
ADO Entity Framework - Assembla Powered By Docstoc
					ADO.NET Entity Framework

El ADO.NET Entity Framework está diseñado para habilitar a los desarrolladores para
crear aplicaciones de acceso a dato programando contra un modelo de conceptual de
aplicación en vez de programar directamente contra un esquema de almacenamiento
relacional. El objetivo es disminuir el monto de código y mantención requerida para
aplicaciones orientadas a datos. Las aplicaciones del Entity Framework proporcionan los
siguientes beneficios:

      Las Aplicaciones pueden trabajar en términos de un modelo conceptual más centrado en
       la Aplicación, incluyendo tipos con herencia, miembros complejos, y relaciones,
      Las Aplicaciones están libres de dependencias de código sobre algún motor de datos o
       esquema de almacenamiento.
      El Mapeo entre el modelo conceptual de la Aplicación y el esquema de almacenamiento
       especifico de almacenamiento pueden cambiar sin tocar el código de la Aplicación,
      Los Desarrolladores pueden trabajar con un consistente modelo de objetos de la
       Aplicación que pueden ser mapeados a varios esquemas de almacenamiento,
       posiblemente implementados en diferentes sistemas de administración de base de datos.
      Múltiples modelos de Aplicación pueden ser mapeados a un solo esquema de
       almacenamiento.
      El soporte de Linq proporciona validación de sintaxis en tiempo de compilación para
       consultas contra el modelo conceptual.
Introducción al Entity Framework

El Entity Framework es un conjunto de tecnologías en ADO.NET que soportan el
desarrollo de aplicaciones de software orientadas a los datos. El Entity Framework habilita
a los desarrolladores a trabajar con datos en la forma de objetos y propiedades específicas
de dominio, tales como clientes y direcciones de cliente, sin que se preocupen en las tablas
de base de datos y columnas donde estos datos están almacenados.

El beneficio primario del ADO.NET Entity Framework es elevar el nivel de abstracción en
el cual los desarrolladores pueden trabajar cuando tienen que trabajar con datos,
decrementando el código que es requerido para crear y mantener aplicaciones orientadas a
datos.

Trasfondo

Los Arquitectos y Desarrolladores de Aplicaciones orientadas a datos han luchado con la
necesidad de lograr dos objetivos muy diferentes. Ellos deben modelar las entidades, las
relaciones, y la lógica de los problemas de negocio que ellos están resolviendo, y deben
también trabajar con los motores de datos usados para almacenar y recuperar datos. Los
datos pueden abarcar múltiples sistemas de almacenamiento, cada uno con sus propios
protocolos; hasta aplicaciones que trabajan con un solo sistema de almacenamiento deben
balancear los requerimientos de el sistema de almacenamiento contra los requerimientos de
escribir código de aplicación mantenible y eficiente. En los primeros días de la
programación, las aplicaciones consistían en librerías de funciones para ejecutar tareas
específicas. La interacción con datos toma la forma de varios procedimientos discretos para
recuperar y modificar datos. Este estilo de programación gradualmente dio camino a
técnicas de orientación a objetos que reemplazaron las librerías de funciones planas con
sistemas mas fácilmente accesibles y mantenibles de clases interrelacionadas que contienen
propiedades, métodos y eventos.

La programacion Orientada a Objetos creo nuevos desafios para interactuar con sistemas de
almacenamiento de datos. A pessar de que la organizacion de clases a menuedo refleja
estrechamente la organizacion de tablas de base de datos relacionales, el ajuste no es
perfecto. Multiples tablas normalizadas a menudo conrresponden a una sola clase, una
relacion entre clases es representrada de manera distinta que una relacion entre tablas. Por
ejemplo, para representar al cliente para una orden de venta, un clase Orden usa una
propiedad que contiene una referencia a una instancia de una clase Cliente, pero una fila de
la tabla Orden en la base de datos contiene una columna con una llave foranea ( o conjunto
de columnas ) con un valor correspondiente a el valor de la llave primaria en la tabla
Cliente. Una clase Cliente podria tener una propiedad llamada Ordenes que contiene una
coleccion de instancias de la clase Orden, pero la tabla Cliente en la base de datos no tiene
una columna comparable.
Conectando Objectos a Datos

In electrical engineering, the difficulty of one system to handle inputs from another system
is called an impedance mismatch, a term often applied to the difficulty of connecting
object-oriented programming systems to stored data. The ADO.NET Entity Framework
addresses this impedance mismatch between object-oriented programming and data storage.

Rather than supporting direct mapping of object-oriented classes and properties to
relational tables and columns, the Entity Framework maps relational tables, columns, and
foreign key constraints to entities and relationships in conceptual models. The Entity
Framework generates extensible classes that developers can use to work with the entities
and relationships in the conceptual model. Instances of these classes are populated with
data and data changes are saved based on the defined mappings between the conceptual and
storage models.

   Giving Life to Conceptual Models

A longstanding and common design pattern for data modeling is the division of the data
model into three parts: a conceptual model, a logical model, and a physical model. The
conceptual model defines the entities and relationships in the system being modeled. The
logical model for a relational database normalizes the entities and relationships into tables
with foreign key constraints. The physical model addresses the capabilities of a particular
data engine by specifying storage details such as partitioning and indexing.

The physical model is refined by database administrators to improve performance, but
programmers writing application code primarily confine themselves to working with the
logical model by writing SQL queries and calling stored procedures. Conceptual models are
generally used as a tool for capturing and communicating the requirements of an
application, often as inert diagrams that are viewed and discussed in the early stages of a
project and then abandoned. Many development teams skip the creation of a conceptual
model and begin by specifying tables, columns, and keys in a relational database.

The Entity Framework gives life to conceptual models by enabling them to be
programmable and connected to underlying logical and physical models. Developers who
work with the Entity Framework can write code that operates on conceptual entities and
relationships, relying on the Entity Framework to map those operations to storage-specific
relational commands. This frees applications from hard-coded dependencies on a particular
data engine or even a particular logical model. A storage-specific logical model and the
mapping between it and the conceptual model are captured in an external specification that
can change as needed without changing the application code. An additional benefit is that
developers can work with a consistent conceptual model across multiple storage engines.

   Models, Mappings, and Objects

Using the ADO.NET Entity Framework to develop an application requires creation of a
conceptual entity data model, a storage entity model, and a mapping between the two. This
metadata takes the form of three types of XML files that have corresponding file name
extensions:

      Conceptual schema definition language (.csdl)
      Store schema definition language (.ssdl)
      Mapping specification language (.msl)

Using this metadata, the Entity Framework generates a set of classes that programmers use
to interact directly with the conceptual model and indirectly with the storage model and the
underlying data store. These classes are partial classes that can be extended with additional
members added by the developer. The classes generated for a particular conceptual model
derive from base classes that provide Object Services for materializing entities as objects
and for tracking and saving changes.

Visual Studio 2008 includes an evolving set of tools that help you create data applications
built on an Entity Data Model (EDM). The tools include the EdmGen.exe command-line
tool as well as a Visual Studio item template and a wizard that generates model mapping
schemas.

   Querying and Updating Data as Entities

The classes in the System.Data.EntityClient namespace consist of a .NET Framework data
provider that is storage independent. When you construct an EntityConnection object, you
reference a set of metadata that contains the necessary models and mapping, and also a
storage-specific data provider name and connection string. Once the EntityConnection is
in place, entities can be accessed through the classes generated from the conceptual model.

The Entity Framework generates a class derived from ObjectContext that represents the
entity container in the conceptual model, and this class exposes a SaveChanges method
that triggers updates to the underlying database. These updates can either use SQL
statements automatically generated by the system or they can use stored procedures
specified by the developer.

Entity SQL

The Entity SQL language is a storage-independent dialect of SQL that works directly with
conceptual entity schemas and that supports EDM features such as inheritance and
relationships. When you construct EntityCommand objects, you can use Entity SQL to
specify the text for queries. The Entity Framework works with storage-specific data
providers to translate generic Entity SQL into storage-specific queries. Entity SQL also
provides a useful alternative to Language-Integrated Query (LINQ) for some applications.

LINQ to Entities

LINQ to Entities supports queries against objects representing a conceptual entity data
model. Developers can use LINQ to Entities to create strongly typed, language-integrated
queries against objects representing a conceptual entity data model. LINQ to Entities
queries do not require that you use System.Data.EntityClient objects and Entity SQL
strings in code.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:16
posted:9/24/2011
language:Spanish
pages:5