Wyyme Software: MS Entity Framework

Entity Framework - Part 1

Entity Framework Architecture

Setting up the environment:

Create the First simple Entity Data Model (EDM):

Querying with EDM:

Types of Entities in Entity Framework:

Note: Please Visit MSDN for more info.

Different type of Modelling Types in Entity Framework

Code First development with Entity Framework 4.1

Note: Please visit EF Code-First Tutorial to learn code first in detail.

Simple Code First Example:

Database Initialization:

Database Initialization Strategies in Code-First:

Turn off DB Initializer in Code-First:

Seed Database in Code-First:

Inheritance Strategy in Code-First:

TPH:
http://weblogs.asp.net/manavi/archive/2010/12/24/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-1-table-per-hierarchy-tph.aspx
TPT:
http://weblogs.asp.net/manavi/archive/2010/12/28/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-2-table-per-type-tpt.aspx
TPC:
http://weblogs.asp.net/manavi/archive/2011/01/03/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-3-table-per-concrete-type-tpc-and-choosing-strategy-guidelines.aspx

Configure Domain Classes in Code-First:

DataAnnotation in Code-First:

Fluent API in Code-First:

Visit MSDN for more information on DbModelBulder class.

EntityTypeConfiguration Class in Code-First:

Visit MSDN for more information on EntityTypeConfiguration class.

Fluent API Class Hierarchy:

Configure One-to-One Relationship:

Configure One-to-Many Relationship:

Configure Many-to-Many relationship:

Migration in Code-First:

Automated Migration:

Code-based Migration:

Model First development with Entity Framework

Database First development with Entity Framework 4.0

Entity Lifecycle:

ObjectStateManager:

Create POCO Entity:

Create Self-Tracking Entities:

Entity Relationships:

Querying Entity Graph:

Eager Loading with DBContext

Lazy Loading with DBContext

Explicit Loading with DBContext

Significance of SaveChanges:

Persistence in Entity Framework

Save New Entity with ObjectContext:

Update an Entity with ObjectContext:

Delete an Entity with ObjectContext:

DBContext vs ObjectContexts

Create EDM and DBContext in EF 4.3

DBContext Class

DBSet Class

DBEntityEntry Class

Working with Entity Property Value

Local Data

Execute Raw SQL Query

Validate Entity

Add Entity using DBContext

Add One-to-One Relationship Entity Graph using DBContext

Add One-to-Many Relationship Entity Graph using DBContext

Add Many-to-Many Relationship Entity Graph using DBContext

Update Entity using DBContext

Update One-to-One Entity using DBContext

Update One-to-Many Entity using DBContext

Update Many-to-Many Entity using DBContext

Delete Entity using DBContext

Stored Procedure in Entity Framework:

Execute Stored Procedure using DBContext

Add/Update data using Stored Procedure:

DefiningQuery in Entity Framework:

Data binding with ASP.Net application:

Entity Framework - Part 2

Note:

A mental model captures ideas in a problem domain, while a conceptual model represents 'concepts' (entities) and relationships between them. A Conceptual model in the field of computer science is also known as a domain model. Conceptual modeling should not be confused with other modeling disciplines such as data modelling, logical modelling and physical modelling. The conceptual model is explicitly chosen to be independent of design or implementation concerns, for example, concurrency or data storage. The aim of a conceptual model is to express the meaning of terms and concepts used by domain experts to discuss the problem, and to find the correct relationships between different concepts. The conceptual model attempts to clarify the meaning of various, usually ambiguous terms, and ensure that problems with different interpretations of the terms and concepts cannot occur. Such differing interpretations could easily cause confusion amongst stakeholders, especially those responsible for designing and implementing a solution, where the conceptual model provides a key artifact of business understanding and clarity. Once the domain concepts have been modeled, the model becomes a stable basis for subsequent development of applications in the domain. The concepts of the conceptual model can be mapped into physical design or implementation constructs using either manual or automated code generation approaches. The realization of conceptual models of many domains can be combined to a coherent platform.

A conceptual model can be described using various notations, such as UML, ORM or OMT for object modelling, or IE or IDEF1X for Entity Relationship Modelling. In UML notation, the conceptual model is often described with a class diagram in which classes represent concepts, associations represent relationships between concepts and role types of an association represent role types taken by instances of the modelled concepts in various situations. In ER notation, the conceptual model is described with an ER Diagram in which entities represent concepts, cardinality and optionality represent relationships between concepts. Regardless of the notation used, it is important not to compromise the richness and clarity of the business meaning depicted in the conceptual model by expressing it directly in a form influenced by design or implementation concerns.

Entity Framework model metadata

Approaches to model creation

VS will create Classes based on Conceptual model of entity framework. Our application Business objects will contact these classes to persist data into DB.

Conceptual model in your Apps

Demo of Entity framework operation in VS

Creating Database First Entity Data Models

Mapping to the Database

Modifying an Entity’s Property

Exploring Relationships

Pluralisation will name referenced entities based on Quantity of records and multiplicity

Self referencing Associations

Many to Many Relationship

This feature is hidden in Entity framework by joining entities during query process.

Looking at the model Raw data

Property of entity properties

Making modification to Conceptual model

Updating model from DB

Model-First Entity Data Models

Creating a model from Scratch

Entity Properties

Store Generated Pattern property

Note: This property will be used only in DB Generated scripts not in Model of entity

Defining Relationship between entities

Generating DB schema from the model

Executing DDL (SQL Scripts) to build the Database

Model and DB cascade Delete

Entity Designer DB Generation Power Pack

Note: This tool will help to generate DB scheme for specific object changes not completely

Entity Framework Code First Migrations

Introduction and Automated Migrations

What are Migrations?

Migration solves the problem of modifying your database without completely destroying it. And migrations isn't something that was invented by the EF team just to solve Code First's problem. The concept and some tooling already existed, and the idea is to migrate the database, in other words, automatically updated schema to reflect model changes. This way you don't have to lose data or other changes you've made to the database, but you still have the convenience of automatically aligning the database schema to the current version of the model

Default Behavior with New Databases

Default Behavior when Model Changes

Let me take that one step further. I'll going to domain classes. I'll add in a new property, and I'll run the app again. And here is a somewhat familiar exception. This is something you would have seen with Entity Framework 4.1 and 4.2 also when you change the model. Because the default initializer is create database if not exists, it sees that the database already exists; and somehow it's able to tell that the model's changed since the last time we created the database. But it's doing that without the EDM metadata file. So let me just show you a little secret and that is, instead of the EDM metadata table which normally would have shown up alongside aliases and Tweets, Entity Framework 4.3 creates a migration history table. So in the background it's doing the same type of check that it was doing in 4.1 and 4.2. But this time, instead of looking for the EDM metadata table, it does that against migration history. So Entity Framework looked at the representation of what the model was when I originally created this database.

That representation was stored in migration history. That's how it was able to detect that the model is different than it was before. This is tucked away in system tables. It won't get in your way. And for some people, had I not just shown that to you, you may never have even known that it was there and you might not even care. It just works. The exception message is different. Before it would have told you that you should consider using drop create database if model changes as your initializer; or it even suggested that you might just want to go and manually interact with the database, so make the changes directly to the database. So we're not going to do either of those. With Entity Framework 4.3, it's saying, please use Code First migrations because we worked really hard on them to make you happy. So I'll go ahead and do that.

Enabling Code First Migration (And Automating)

Setting the Database Iniitializer to use Migrations

Either use below Code based initializer

Or we can use below configuration section to set the initialization and RUN the application.

When we execute the application, new property which we changed has added in the DB.

Removing columns in our model class on Automatic migrations

Adding new entity in the context again

So you might be adding other types of objects to your database. Even though you're working with Code First, you might have triggers in it, stored procedures and other types of objects, and you don't have to worry about losing those or having to re-create them.