Fresh Entity Framework Interview Preparation Guide

Download PDF

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:


Added
Deleted
Modified
Unchanged
Detached

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.