Entity Framework 4.0Daniel LacoDirector Ejecutivodaniell@vemn.com.ar
Voto de DesconfianzaEntity Framework in 3.5 SP1 is:Too complex. Too many steps are required.Too many restrictions.  I want control over my code.Not in sync with the way I work: TDD, N-Tier, Patterns
TemarioPersistanceIgnorance (POCO)POCO Change-Tracking (PlainOld CLR Object)T4 Code GenerationLazyLoadingSoporte para N-Capas con Self-Tracking EntitiesModel-FirstDevelopmentCode-OnlyDevelopmentMejoras en el Diseñador de EntidadesPluralizaciónOpciones de Change Tracking
DemoObjetos POCO (PlainOld CLR Object)
DemoLazyLoading
DemoT4
DemoDesarrollo solo por Código
DemoSelf-Tracking Entities
Que hay de nuevo?Plurales / SingularesMejoras en el DiseñadorGeneraciónautomática de tiposretornadospor Stored ProceduresSoporte para Tipos ComplejosForeignKeysMejoras en testing con IObjectSet<T>T-SQL mas performante  y simple de leerMétodos para Ejecutar SQL
Que NOes un ORM? La respuesta a la vida del universo y todo eso …La forma absoluta más rápida de hacer todo …No siempre están en sintonía con los avances de las Bases de Datos …
ResumenPersistanceIgnorance (POCO)POCO Change-Tracking (PlainOld CLR Object)T4 Code GenerationLazyLoadingSoporte para N-Capas con Self-Tracking EntitiesModel-FirstDevelopmentCode-OnlyDevelopmentMejoras en el Diseñador de EntidadesPluralizaciónOpciones de Change Tracking
¿Preguntas?
Muchas graciaspor su participaciónDaniel LacoDirector Ejecutivodaniell@vemn.com.ar
[Run Reloaded] Entity Framework 4.0 (Daniel Laco)

[Run Reloaded] Entity Framework 4.0 (Daniel Laco)

Notas del editor

  • #2 Accediendo a datos con Entity Framework
  • #4 http://msdn.microsoft.com/en-us/library/bb738695.aspx Persistence Ignorance: You can define your own POCO’s (Plain Old CLR Objects) that are decoupled from any specific persistence technology. This allows you to swap out one data access stack for another should the need arise.
  • #5 Nuevos metodos en ObjectStatemManagerObjectStateManager.ChangeObjectStateObjectStateManager.ChangeRelationshipStateObjectStateManager.GetObjectStateEntry(entityObject).ApplyCurrentValuesObjectStateManager.GetObjectStateEntry(entityObject). ApplyOriginalValuesObjectContext.LoadProperty
  • #9 Better N-Tier SupportOne of the most common reasons for using POCO’s is to conceal details of object persistence behind a data access layer. Similarly, POCO’s are often passed across tiers as Data Transfer Objects (DTO’s) in a service-oriented application. One problem that has vexed distributed application developers is how to pass changes from one tier to another so they can be persisted in a disconnected manner. At first, the Entity Framework team decided to provide a low-level API for applying changes to detached objects, requiring you to roll your own change-tracking mechanism, but much of the feedback they received included requests for a built-in change-tracking mechanism and an end-to-end architecture for building n-tier apps that use the Entity Framework. In response to this feedback, the team delivered a T4 template for Self-Tracking Entities, which allows each entity to keep track of its own change state, so that you can pass it to a remote service where the entire object graph is persisted.Each generated class implements the IObjectWithChangeTracker interface, which has a ChangeTracker property, as well as methods to mark the entity as Unchanged, Modified, Added or Deleted. ObjectChangeTracker not only records the object state but also maintains original values of reference properties as well as objects that have been added to or deleted from collection properties. This means that the client can make changes to an Order by adding or removing OrderDetails, and the state of the Order and OrderDetails can be sent to the service for persistence. Change state is serialized because each entity is marked with a [DataContract] attribute and the ChangeTracker is marked with a [DataMember] attribute.Self-Tracking Entities allow the client to track change state on entities without needing to reference the Entity Framework assembly, System.Data.Entity. The change-tracking code is auto-generated by the T4 template, which produces the ObjectChangeTracker class and a generic FixupChangeTrackingCollection class that does relationship fix-up and implements ICollection to keep track of additions and deletions. Deleted items are cached so they can be removed later when changes are persisted on the service side.Your service would typically expose a method for retrieving an object graph such as Order and OrderDetails, and a method for updating the object graph. In the update method, you would call ApplyChanges<T> on the appropriate entity set. ApplyChanges is an extension method residing in the Microsoft.Data.Entity.CTP assembly, which you bring into scope by adding a using directive for the Microsoft.Data.Entity namespace. This method accepts an object graph as well as a pointer to a method that returns an IEntityChangeTracker, which is responsible for informing the object state manager of these changes. The Self-Tracking Entities T4 template also generates a EntityChangeTrackerAdapter class that implements IEntityChangeTracker by translating the persistence-neutral ObjectStateenum (Added, Deleted, Modified, Unchanged) to the equivalent EF-specific EntityStateenum values. The code in your service-side update method could look something like this:public Order UpdateOrder(Order order){    using (NorthwindEntitiesctx = new NorthwindEntities())    {        ctx.Orders.ApplyChanges(order,            EntityChangeTrackerAdapter.GetSelfTrackingEntityInfo);        ctx.SaveChanges();        return order;    }}
  • #10 http://code.msdn.microsoft.com/DesignerExtStartKit (ADO.NET Entity Data ModelDesignerExtensionStarter Kit )T-SQL mas performante Se mejoraron los Joins Se sacaron Cast innecesarios Se sacaron algunos IsNull innecesariosContains, StartWidh y EndWith ahora son Like %%
  • #12 http://msdn.microsoft.com/en-us/library/bb738695.aspx Persistence Ignorance: You can define your own POCO’s (Plain Old CLR Objects) that are decoupled from any specific persistence technology. This allows you to swap out one data access stack for another should the need arise.
  • #14 Accediendo a datos con Entity Framework