Entity Framework

What is an Entity?

Entities are instances of EntityTypes; they represent the individual instances of the objects (such as candidates, opening) to which the information pertains. The identity of an entity is defined by the entity type it is an instance of; in that sense an entity type defines the class an entity belongs to and also defines what properties an entity will have. Properties describe some aspect of the entity by giving it a name and a type. The properties of an entity type in ADO.NET Entity Framework are fully typed, and are fully compatible with the type system used in a DBMS system, as well as the Common Type System of the .NET Framework.

What is Entity Framework?
The ADO.NET Entity Framework enables developers to create data access applications by programming against a conceptual application model instead of programming directly against a relational storage schema. The goal is to decrease the amount of code and maintenance required for data-oriented applications. Entity Framework applications provide the following benefits:

• Applications can work in terms of a more application-centric conceptual model, including types with inheritance, complex members, and relationships.

• Applications are freed from hard-coded dependencies on a particular data engine or storage schema.

• Mappings between the conceptual model and the storage-specific schema can change without changing the application code.

• Developers can work with a consistent application object model that can be mapped to various storage schemas, possibly implemented in different database management systems.

• Language-integrated query (LINQ) support provides compile-time syntax validation for queries against a conceptual model.

ADO.NET Entity Framework abstracts the relational (logical) schema of the data that is stored in a database and presents its conceptual schema to the application. For example, in the database, entries about a candidate and their information can be stored in the Candidates table, their opening in the Openings table and their contact information in yet another Contacts table. For an application to deal with this database, it has to know which information is in which table, i.e., the relational schema of the data is hard-coded into the application.

The disadvantage of this approach is that if this schema is changed the application is not shielded from the change. Also, the application has to perform SQL joins to traverse the relationships of the data elements in order to find related data. For example, to find the opening of a certain candidate, the candidate needs to be selected from the Candidates table, the Candidates table needs to be joined with the Opening table, and the joined tables need to be queried for the opening that are linked to the candidate.

This model of traversing relationships between items is very different from the model used in object-oriented programming languages, where the relationships of an object’s features are exposed as Properties of the object and accessing the property traverses the relationship. Also, using SQL queries expressed as strings, only to have it processed by the database, keeps the programming language from making any guarantees about the operation and from providing compile time type information.

The mapping of logical schema into the physical schema that defines how the data is structured and stored on the disk is the job of the database system and client side data access mechanisms are shielded from it as the database exposes the data in the way specified by its logical schema.

Why we should use Custom Entities instead of Dataset?
In order to use a Dataset inside the presentation layer, we need to have knowledge about data structures (i.e. tables, columns and rows hosted by the Dataset), so we don’t have real abstraction from the data layer. Anyway a Dataset makes easier to develop data binding code.
Custom Entities are usually slim, from an XmlSerialization point of view, and there are also tools, like System.Xml.Serialization attributes, to make it even slimmer.
We’ve to pay the due to fill the entities with our data, being careful of not building monster with multiple heads, with GB and GB of RAM filled with data that should be kept inside the DBMS engine. Remember that custom entities are the containers of small instance data and not a replacement for your DBMS, like Dataset.
Custom entities provide the means to expose real data in easy-to-access APIs without forcing every data model to fit in the relational model. Like it or not, in the real world all data is rarely entirely relational. By using Datasets, you render data with some approximation, albeit without loss of information.
Custom entities supply strong typing and more compact, faster objects. At the same time, they are abstract enough to require no changes to the DAL if the underlying database schema changes. Being custom classes, they enable you to incorporate information aggregated from multiple sources and represent free-form and hierarchical data. A custom class can be marked as serializable and serialized through any super-optimized algorithm.

Dataset Custom Entities
Built-in support for concurrency Yes To be added
Data Relationship Yes No
Serialization Inefficient in .NET Framework 1.x To be added
NULL values No To be added
Schema abstraction Yes Yes
Strong typing No Yes
Support for hierarchical data Yes, but through a relational API Yes
Free-form data No Yes
Custom behavior No Yes
Ease of development Yes No, but can be improved through code generation
.NET data binding Yes To be added; requires the implementation of several additional interfaces
Interfacing with Web services Costly, unless knowledge of the object is assumed on the client Yes
XML integration Yes To be added
Expression language Yes To be added
Data aggregation Yes To be added
Why do we need interfaces?
Interfaces are a very logical way of grouping objects in terms of behavior. When multiple developers start building a large scale ASP.NET application, the site’s design often suffers from two common problems:
1. Quality control
2. Flexibility
One reason quality control suffers is because it is natural for developers to give the functionality of their components different method names. For example three developers creating similar components may opt to name related functions with different names. Second, flexibility will suffer unless there is a convenient way to reference dynamically called components. For example, imagine a particular ASP.NET page loads a set of User Controls specified through querystring values. Once these controls have been loaded, they each might have differently named methods or properties that need to be called / set. With a gaggle of different User Controls that could be loaded, and each with different method and property names, the page’s source code will quickly become unreadable.
It is possible, though, to solve these quality control and flexibility issues through the use of .NET interfaces.
During the process of designing an application using OOP Paradigm, the application will be designed as a set of classes indicating how objects will be created each with specific status and behavior, as well as defining the ways of interaction between those objects. By this way, almost every class indicates a type (an abstracted data type in a more specific manner).
Interfaces also enhance abstraction which is a core principal of OOP; design patterns like the factory pattern make a perfect use of interfaces through abstracting objects to know which implementation of a certain object type is provided. Interfaces make it very flexible to change implementations of services especially in multilayer applications.
Another benefit of interfaces shows up during the development of large projects by large teams, at which the interface acts as a specification for developers with the set of methods they need to implement in classes of a certain type.
Why “Microsoft Data Access Application Block”?
The Data Access Application Block is a Microsoft .NET Framework component that contains optimized data access code that can help you do the following:

• Call stored procedures.

• Issue SQL text commands against a SQL Server database.
The Enterprise Library Data Access Application Block simplifies development tasks that implement common data access functionality. Applications can use the application block in a variety of situations, such as reading data for display, obtaining data to pass through application layers, and submitting changed data back to the database system. The application block includes support for both stored procedures and in-line SQL, and common housekeeping tasks such as managing connections and creating and caching parameters are encapsulated in the application block’s methods. In other words, the Data Access Application Block provides access to the most frequently used features of ADO.NET.
The application block also facilitates the development of portable application code, allowing the code to remain uniform across multiple database servers, including Microsoft SQL Server, Oracle, and DB2. It does so by using an abstract base class that defines a common interface and provides much of the implementation for the data access methods, Applications written for one type of database such as SQL Server look the same as applications written for another type of database, such as Oracle. By using the Data Access Application Block and by following the guidelines in this document, your code remains mostly portable.

The Data Access Application Block has the following features:

• It reduces the need to write boilerplate code to perform standard tasks.

• It helps maintain consistent data access practices, both in an application and across the enterprise.

• It reduces difficulties in changing the physical database target.

• It relieves developers from learning different programming models for different types of databases.

• It reduces the amount of code that needs to be rewritten when porting applications to different types of databases.