2. Voto de Desconfianza Entity 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
3. Temario PersistanceIgnorance (POCO) POCO Change-Tracking (PlainOld CLR Object) T4 Code Generation LazyLoading Soporte para N-Capas con Self-Tracking Entities Model-FirstDevelopment Code-OnlyDevelopment Mejoras en el Diseñador de Entidades Pluralización Opciones de Change Tracking
9. Que hay de nuevo? Plurales / Singulares Mejoras en el Diseñador Generaciónautomática de tiposretornadospor Stored Procedures Soporte para Tipos Complejos ForeignKeys Mejoras en testing con IObjectSet<T> T-SQL mas performante y simple de leer Métodos para Ejecutar SQL
10. 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 …
11. Resumen PersistanceIgnorance (POCO) POCO Change-Tracking (PlainOld CLR Object) T4 Code Generation LazyLoading Soporte para N-Capas con Self-Tracking Entities Model-FirstDevelopment Code-OnlyDevelopment Mejoras en el Diseñador de Entidades Pluralización Opciones de Change Tracking
13. Muchas graciaspor su participación Daniel Laco Director Ejecutivo daniell@vemn.com.ar
Notas del editor
Accediendo a datos con Entity Framework
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.
Nuevos metodos en ObjectStatemManagerObjectStateManager.ChangeObjectStateObjectStateManager.ChangeRelationshipStateObjectStateManager.GetObjectStateEntry(entityObject).ApplyCurrentValuesObjectStateManager.GetObjectStateEntry(entityObject). ApplyOriginalValuesObjectContext.LoadProperty
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; }}
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 %%
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.