A defining query allows you to execute a native SQL statement that is specified in the DefiningQuery element in the EntitySet element in the SSDL.
A defining query is commonly used to provide functionality similar to that provided by a database view, but this native SQL statement will be in the .edmx file, not in the database. The entityset in CSDL is used to surface data exposed by the defining query.
So here, we will see how we can execute same SQL using DifiningQuery which we used in database view in previous chapter and get the same functionality as database view.
We will perform following three steps to create and use DefiningQuery:
Add DefiningQuery in SSDL
Add EntitySet in CSDL
Mapping between Conceptual and Storage EntitySets
When an entity has relation with other entities then it called entity graph because more entities are involved, for example Student entity graph includes many other entities like Standard, StudentAddress & Course.
Disconnected scenario is when an entity is retrieved from the database and modified in the different context. Disconnected scenario is complex because context doesn't know anything about modified entity so you have to tell to ObjectContext that what has changed in entity.
Connected scenario is when an entity is retrieved from the database and modified in the same context.
During entity's lifetime, each entity has an entity state based on operation performed on it via Context (ObjectContext). The entity state is an enum of type System.Data.EntityState that declares the following values:
In Model First approach, you create Entities, relationships, and inheritance hierarchies directly on the design surface of EDMX. So in Model First approach, when you add ADO.NET Entity Data Model, you should select ‘Empty Model' instead of ‘Generate from database'.
In Code First approach, you avoid working with visual model designer (EDMX) completely. You write your POCO classes first and then create database from these POCO classes. Developers who follow the path of Domain-Driven Design (DDD) principles prefer to begin by coding their classes first and then generating the database required to persist their data.
POCO Proxy is a runtime proxy class of POCO entity. POCO entity becomes POCO Proxy entity if it meets certain requirements to enable lazy loading proxy and instant change tracking. It adds some methods at runtime to your POCO class which does instant change tracking and lazy loading stuff.
POCO entity should meet the following requirement to become POCO proxy:
A custom data class must be declared with public access.
A custom data class must not be sealed (NotInheritable in Visual Basic)
A custom data class must not be abstract (MustInherit in Visual Basic).
A custom data class must have a public or protected constructor that does not have parameters.
The class cannot implement the IEntityWithChangeTracker or IEntityWithRelationships interfaces because the proxy classes implement these interfaces.
The ProxyCreationEnabled option must be set to true.
Each navigation property must be declared as public, virtual
Now if you expand ‘Entities' region, you can see many partial classes that are derived from EntityObject. This classes are EntityTypes of you model.
IObjectSet is a interface which gives collection like functionality. ObjectSet<> also implements IObjectSet. IObjectSet is useful in unit testing where you can create fake EntitySet (of type IObjectSet<>). We have used IObjectSet in our sample project.
Each EntitySet in context class is a type of ObjectSet<> that wraps the entity. e.g. ObjectSet.
Now, if you open designer.cs, you can see two main regions, Contexts and Entities. Expand contexts region. You can see partial class with suffix ‘entities' and derived from ObjectContext class.
AssociationSet defines the relation between each EntitySet.
EntityType is a datatype in the model. You can see each EntityType for your conceptual model in XML. If you expand EntityType node in XML, you can see each properties and its type and other info.
EntitySet is a container for EntityType. It is set of same entitytype. You can think it like db table.
EntityContainer is a wrapper for EntitySets and AssociationSets. It is critical entry point for querying the model.
EDM designer represents your conceptual model. It consists Entities, associations & multiplicity between the entities. Initially it will exactly look like your database table structure but you can add or merge columns or remove columns which are not required by your application from this designer. Even you can add new object in this model which can have columns from different database tables from context menu as shown in above figure. Remember, whatever changes you do here it should be mapped with storage model. So you have to be careful while doing any changes in the designer.
This layer communicates with database using standard ADO.Net.
The main responsibility of this layer is to convert L2E or Entity SQL queries into SQL query which is understood by underlying database. It communicates with ADO.Net data provider which in turn sends or retrieves data from database.
Object service is a main entry point for accessing data from database and to return it back. Object service is responsible for materialization which is process of converting data returned from entity client data provider (next layer) to an entity object structure.
Entity SQL is again a query language same as LINQ to Entities. However it is little more difficult than L2E and also developer need to learn it separately.
LINQ to Entities is query language used to write queries against the object model. It returns entities which are defined in the conceptual model. You can use your LINQ skills here.
Mapping consist information about how your conceptual model is mapped to storage model.
Storage model is your database design model which includes tables, views, stored procedures and their relationships and keys.
Conceptual model is your model classes and their relationships. This will be independent from your database table design.
EDM consist three main parts- Conceptual model, Mapping and Storage model.
Entity framework has a full provider model. It supports not only SQL Server but also other database like Oracle, DB2, MySQL etc.
Most of the time L2S classes must be one-to-one with database objects e.g. Customer class can be mapped only with Customer table. Where as in Entity Framework you can map your domain class with multiple tables using various inheritance strategies like table per type (class) or table per hierarchy of classes etc.
You can have multiple modeling techniques using Entity Framework 4.1 like code first, model first or database first.
Microsoft has long term strategy to support and integrate Entity Framework with multiple Microsoft products.
The Microsoft ADO.NET Entity Framework is an Object/Relational Mapping (ORM) framework that enables developers to work with relational data as domain-specific objects, eliminating the need for most of the data access plumbing code that developers usually need to write. Using the Entity Framework, developers issue queries using LINQ, then retrieve and manipulate data as strongly typed objects. The Entity Framework's ORM implementation provides services like change tracking, identity resolution, lazy loading, and query translation so that developers can focus on their application-specific business logic rather than the data access fundamentals.
To simply say it: Entity framework is an Object/Relational Mapping (O/RM) framework. It is an enhancement to ADO.NET that gives developers an automated mechanism for accessing & storing the data in the database and working with the results in addition to DataReader and DataSet.
Now the question is what is O/RM framework and why do we need it?
ORM is a tool for storing data from domain objects to relational database like MS SQL Server in an automated way without much programming. O/RM includes three main parts: Domain class objects, Relational database objects and Mapping information on how domain objects maps to relational database objects (tables, views & storedprocedures). ORM helps us to keep our database design separate from our domain class design. This makes application maintainable and extendable. It also automates standard CRUD operation (Create, Read, Update & Delete) so developer doesn't need to write it manually.