Database Reference
In-Depth Information
Following is the output of the code in Listing 7-2:
Customers
---------
Jill Nickels
Robert Cole
How It Works
The first part of the code in Listing 7-2 should be very familiar to you by now. We use Entity Framework to create
a new context, create a few entities, and call
SaveChanges()
to persist the entities to the database. To retrieve the
entities, we iterate through the collection and display each on the console. The only difference in this part is the call
to
ContextFactory.CreateContext()
.Normally, we would just use the
new
operator to get a new instance of our
EFRecipesEntities context.
We've created the ContextFactory to create our context from the model metadata stored, not in the .edmx file,
but in a table in a database. We do this in the
CreateContext()
method. The
CreateContext()
method creates a new
EntityConnection based on two things: a workspace that we create with the
CreateWorkSpace()
method and a SQL
connection string. The real work happens in how we create the workspace in the
CreateWorkSpace()
method.
The
CreateWorkSpace()
method opens a connection to the database where our metadata is stored. We construct
a SQL statement that reads the one row from the Definitions table (refer to Figure
7-2
) that holds our definitions
for the conceptual layer, storage layer, and mapping layer. We read these definitions with XmlReaders. With these
definitions, we create an instance of a MetadataWorkspace. A MetadataWorkspace is an in-memory representation
of a model. Typically, this workspace is created by the default plumbing in Entity Framework from your .edmx file.
In this recipe, we create this workspace from the definitions in a database. There are other ways to create this
workspace including using embedded resources and an implementation with Code First.
The code in Listing 7-2 uses POCOs for our Customer entity. We cover POCO extensively in Chapter 8, but here
we use POCO to simplify the code. With POCO, we don't use the classes generated by Entity Framework. Instead,
we use our own classes that have no particular dependence on Entity Framework. In Listing 7-2, we created our own
definition of the Customer entity in the Customer class. We also created our own object context: EFRecipesEntities.
Our context, of course, does have a dependence on Entity Framework because it derives from ObjectContext.
7-3. Deploying a Model
Problem
You want to know the various options for deploying a model.
Solution
When you add a new ADO.NET Entity Data Model to your project, Entity Framework sets the Build Action property for
the .edmx file to Entity Deploy. Additionally, the Metadata Artifact Processing property of the model is set to Embed
in Output Assembly. When you build your project, the Entity Deploy action extracts three sections from the .edmx
file into three separate files. The CSDL section is extracted into the
Model.csdl
file. The MSL section is extracted into
the
Model.msl
file. The SSDL section is extracted into the
Model.ssdl
file. With the Embed in Output Assembly, these
three files get embedded into the assembly as resources.
Changing the Metadata Artifact Processing property to Copy to Output Directory causes the three
Model.*
files to
be copied to the same directory as the resulting assembly. The files are not embedded as a resource.
