Entity Framework 4.0 Features(转)
• Plurality Naming Support
• Complex Type Support
• Customized Object Layer Code Generation
• Model Browser Improvements
The following sections will briefly discuss each item. A more detailed discussion of each item is
included throughout the book.
POCO Support
One of the more powerful new features of the Entity Framework is the ability to add and use your own
custom data classes in conjunction with your data model. This is accomplished by using CLR objects,
commonly known as “POCO” (Plain Old CLR Objects). The added benefit comes in the form of not
needing to make additional modifications to the data classes. This is also called persistence-ignorance.
The flexibility of extending these partial classes means more control over the core entity object
functionality. This is a huge advantage as developers can now leverage and preserve valuable
customizations and business logic, which they might not have been able to do previously.
Model-First Support
In the first version of the Entity Framework, developers could create a conceptual model using the
Create Database Wizard, but that model could not be persisted (created) based on that model. This
changes with the ADO.NET 4.0 Entity Framework.
When creating your initial conceptual model via the Create Database Wizard you can now create the
database based on the conceptual model. This is a huge plus for developers who like to create the object
model first and generate the database based on the model. This functionality supports the data-driven
design that the EDM is purely based on.
Related Object–Deferred Loading
Deferred loading is also known as lazy loading, and in the first version of the Entity Framework, related
objects were not automatically loaded from the data source as navigation properties were accessed.
In ADO.NET 4.0 Entity Framework, query results can be shaped by composing queries that explicitly
navigate the relationships via the navigation properties.
LINQ-to-Entities Function Support
Function support in the first version of the Entity Framework was limited. A function represented either
a stored procedure or a UDF in the database.
Two new classes have been added to the Entity Framework for this release to address this issue, the
EntityFunctions and SqlFunctions classes. These classes provide developers the ability to access
canonical and database functions via LINQ to Entities queries.
Additionally, a new attribute called EdmFunctionAttribute gives the Entity Framework the ability to
use a CLR method to serve as a proxy for a function defined in the conceptual model.
Plurality Naming One of the big complaints in the first version of the Entity Framework was how naming conventions were applied to EDM objects such as entities and navigation properties when using the model wizards.
The first version of the Entity Framework gave the Entity Name and the Entity Set Name the same name.
There was no attempt to singularize or pluralize names when generating a model from a database.
The problem is that this caused some confusion when referencing the database table or EntityType
in code. For example, if your database has a table called Employees, then you will also get an EntityType
called Employees as well. This causes confusion about whether you are referencing the table or the
EntityType, such as in the code fragment below.
Customers customer = new Customers();
Luckily, this issue has been addressed. The model wizards, both the Entity Data Model and Update
Model Wizards, now provide the option of using singular or plural forms of names for entities, entity
sets, and navigation properties.
The goal of this change was to make the application code much easier to read and avoid a lot of the
confusion between object names.
Complex Types
A big addition to this version of the Entity Framework is the support for complex types. Complex types
are like entities in that they consist of a scalar property or one or more complex type properties. Thus,
complex types are non-scalar properties of entity types that enable scalar properties to be organized
within entities.
Customized Object-Layer Code Generation
Object-layer code is generated, by default, by the EDM using the Entity Model Code Generator tool. This
version of the Entity Framework allows developers to add text templates to a project that replaces the
default tool to generate the object-layer code.
By using custom text templates, the EDM will generate the object context and entity classes. The
Entity Framework makes it very easy to add custom templates via the EDM.
Model Browser Improvements
Several improvements have been made to the model browser that make working with the EDM much
more pleasant. Improvements include the following:
• Updating the model when changes are made to the underlying database.
• Deleting objects from the model.
• Searching for a specified string in the storage and conceptual models.
• Locating entity types on the design surface.
This list is by no means complete, as many more improvements have been made to the model
browser
Back-End Support
The great thing about the Entity Framework is that in essence it does not really care about the data store
from which the data is being queried. It doesn’t need to. Neither the type of database nor the schema
itself is completely unknown to the Entity Framework, and they will have no impact on your model.
Out of the box, the Entity Framework ships with two providers:
• EntityClient Provider for the Entity Framework: Used by Entity Framework
applications to access data described in the EDM. This provider uses the .NET
Framework Data Provider for SQL Server (SqlClient) to access a SQL Server
database.
• NET Framework Data Provider for SQL Server (SqlClient) for the Entity
Framework: Supports the Entity Framework for use with a SQL Server database.
The great thing about the Entity Framework is that it is database-, or data source–, independent, in
that you can create custom providers to access other databases. For example, through third party
providers you can access the following:
• Oracle
• MySql
• PostgreSQL
• SQL Anywhere
• DB2
• Informix
• U2
• Ingres
• Progress
• Firebird
• Synergy
• Virtuoso
This is quite a list and it shows you that the Entity Framework is gaining in popularity. This list is by
no means complete, as providers are continuously being created by third-party vendors. At the time of
this writing, a complete list of providers and their vendors can be found here:
http://msdn.microsoft.com/en-us/data/dd363565.aspx
The great thing about this is that the provider does all of the work for you pertaining to query
reshaping. You are responsible for providing the connection information to the specific data store, but
the provider takes care of the rest when working with the Entity Framework. Why? Because of the need
to learn databases or figure out the nuances of different data stores. Instead, you use the Entity
Framework’s query syntax such as LINQ to Entities or Entity SQL and forgo the headache of
remembering the database differences.
Through .NET Framework Data Provider for SQL Server (SqlClient) for the Entity Framework
you can use SQL Server as far back as version SQL Server 2000 up through SQL Server 2008. Microsoft
even supports SQL Server Compact Edition.
