Entity Framework (1)--connections and Models

Original: https://msdn.microsoft.com/en-us/data/jj592674

Should choose Codefirst, Modelfirst or Databasefirst online already a lot of information, here not much to say.

This article mainly contains how EF discovers which database connection to use and how to change it. Models can be created with the Codefirst and EF designers.

Typically, an EF application will have a class that inherits from DbContext, which invokes a constructor of the base class DbContext, which is used by the EF application to control the following content, which is also referred to as the context class in this article:

1. How the context connects to a database-for example, how connection string is discovered and used

2. Context is to create a model with Codefirst or to create a model with the EF Designer

3. Other Advanced options

• Contract Connection using Codefirst (create connection according to EF Convention)

If you do not have any configuration in your application, calling DbContext's parameterless constructor uses Codefirst mode to create a database and its connections by convention. The Convention is that the database name is the namespace of the context class + "." + Context class name. For example:

Namespace Demo.ef
{
public class Bloggingcontext:dbcontext
{
Public Bloggingcontext ()
C # would call base class parameterless constructor by default
{
}
}
}

In this example, a database with "Demo.EF.BloggingContext" as the database name is created in SQL Express or Loacl db, where "Demo.ef" is the namespace in which the context class resides, "Bloggingcontext "is the name of the context class. At this point, you go to view the profile discovery, without adding any string information related to the database connection. In fact, EF defaults to the native lookup of a database named "Demo.EF.BloggingContext" in SQLExpress or LocalDB.

LocalDB is installed by default in SQL express,vs2012 installed in VS2010, and if SQL Express and LocalDB are installed, then EF chooses to create a database in SQL Express.

• Use the Codefirst convention to connect and specify the database name

If you do not have any configuration in your application, you can give it a string parameter when you call the constructor, which will create a database with the name of the parameter. For example:

public class Bloggingcontext:dbcontext
{
Public Bloggingcontext (): Base ("Bloggingdatabase")
{
}
}

In the example, a database named "Bloggingdatabase" will be created in SQL Express or LocalDB. Similarly, if both SQL Express and LocalDB are installed, then EF chooses to create a database in SQL Express.

• Using the Codefirst and connection string in the configuration file

You can also choose to first set the connection string in the configuration file first. For example:

<configuration>
<connectionStrings>
<add name= "Bloggingcompactdatabase"
Providername= "system.data.sqlserverce.4.0"
connectionstring= "Data source=blogging.sdf"/>
</connectionStrings>
</configuration>

Then, when you create the database context, use the following code:

public class Bloggingcontext:dbcontext
{
Public Bloggingcontext (): Base ("Bloggingcompactdatabase")
{
}
}

At this point, when the database is created, the server and database names specified in ConnectionString are used.

You'll find that the code that creates the database context here is very similar to the previous section, except that the parameter names are different. In fact, when the above code executes, EF first looks for a connection string in the configuration file that is not named "Bloggingcompactdatabase", and if so, connects to the database (created automatically when the database is not created). If not, a database named "Bloggingcompactdatabase" is created in SQLExpress or LocalDB.

Alternatively, you can use "Name=<connection string name>" as the argument for the constructor of the base class DbContext. For example:

public class Bloggingcontext:dbcontext
{
Public Bloggingcontext ()
: Base ("Name=bloggingcompactdatabase")
{
}
}

Note: This form clearly indicates that a connection string named "Bloggingcompactdatabase" needs to be found in the configuration file and throws an exception if it is not found.

• Using the connection string in Database/model first and configuration files

Unlike Codefirst, the models is created through the EF designer, and the models typically modelfirst the presence of a emdx file.

The designer adds an EF connection string to the configuration file. This connection string is special, and it includes how to get information from the edmx file. For example:

<configuration>
<connectionStrings>
<add name= "Northwind_entities"
Connectionstring= "metadata=res://*/northwind.csdl|
res://*/northwind.ssdl|
RES://*/NORTHWIND.MSL;
Provider=system.data.sqlclient;
Provider Connection string=
&quot;data source=.\sqlexpress;
Initial Catalog=northwind;
Integrated security=true;
multipleactiveresultsets=true&quot; "
Providername= "System.Data.EntityClient"/>
</connectionStrings>
</configuration>

The EF Designer generates the following code, which tells DbContext to use the connection string by passing the name of the connection string.

public class Northwindcontext:dbcontext
{
Public Northwindcontext ()
: Base ("Name=northwind_entities")
{
}
}

Instead of using Codefirst to calculate from code, DbContext will load the existing model, because the connection string is an EF Connection string that contains the details of the model used.

• Other constructor selections for DbContext

The DbContext class contains additional constructors and usage patterns that are suitable for a number of more complex scenarios. Specifically, you can refer to the original

From for notes (Wiz)

Entity Framework (1)--connections and Models