codefirst多个数据库

A. 如何使用CodeFirst进行数据迁移

如果你还在为
支持xxx上下文的模型已在数据库创建后发生更改。请考虑使用 Code First 迁移更新数据库
找到你的数据库上下文所在的类库（一般都是写在项目中的model中，也有的独立model类库）
打开Nuget 程序包管理控制台
输入：Enable-Migrations 回车
如果正确的话 则显示已为项目 xxx启用 Code First 迁移。
我在这里说下 几种有可能出现的错误：
1.No context type was found in the assembly xxx
在当前项目中 没有找到数据库上下文，也就是DbContext 继承的的 "数据库.cs"
2.The EntityFramework package is not installed on project xxx
当前项目已经找到了数据上下文，但是没有EntityFrameWork 需要安装输入 install-package entityframework(手大的 不知道对不对）
基本就这两个问题，如果安装成功则在项目中 出现Migrations文件夹，里面会记录每次数据迁移所发生的变化。
非常好用，不用再删除数据库 重新生成 数据丢失等问题。
常用语句 ：enable-Migrations -Force 替换迁移数据文件 update-database 更新 add-migration 添加新的更新文件

B. EF中的code first模式 怎么创建数据库

方法/步骤

• 1

  EF的Code First模式不需要我们创建什么数据向导，直接写代码就行了。我们用NET最简单的控制台应用程序来说明。如下图所示

  

• 7

  通过以上的步骤，你感觉到EF的Code First模式的魅力了没，自动创建数据库以及表。这也是现在应用最多的模式了，好了，这次分享就到这里。有什么问题的话，留言咨询即可。

C. MVC4+EFcodefirst中如何处理数据库历史记录的保存和查询

二、查询问题分析
(一) 数据查询应该在哪做
在EF中，面向对象的数据查询主要提供了两种方式：
TEntity DbSet<TEntity>.Find(params object[] keyValues)：针对主键设计的通过主键查找单个实体，会先在EF的本地数据集Local中进行查询，如果没有，再去数据库中查询。
IQueryable<T>、IEnumerable<T>类型的所有数据查询的扩展方法（由于DbSet<T>继承于IQueryable<T>与IEnumerable<T>），如SingleOrDefault，FirstOrDefault，Where等。其中IQueryable<T>的扩展方法会先收集需求，到最后一步再生成相应的SQL语句进行数据查询；而IEnumerable<T>的扩展方法则是在查询的第一步就生成相应的SQL语句获取数据到内存中，后面的操作都是以内存中的数据为基础进行操作的。
以上两种方式为EF的数据查询提供了极大的自由度，这个自由度是我们在封装的时候需要保持的。但是，在阅读不少人（其中不乏工作了几年的）对EF的封装，设计统一的数据操作接口Repository中关于数据查询的操作中，通常会犯如下几种失误：
设计了很多GetByName，GetByXX，GetByXXX的操作，这些操作通常并不是所有实体都会用到，只是部分实体的部分业务用到，或者是“估计会用到”。
定义了按条件查询的SingleOrDefault，FirstOrDefault，Count，GetByPredicate(predicate)等方法，但是对于条件predicate的类型是使用Expression<Func<TEntity, boo>>还是Func<TEntity, bool>很纠结，最后干脆两个都设计，相当于把IQueryable<T>，IEnumerable<T>的方法再过一遍。
定义了获取全部数据的GetAll()方法，但却使用了IEnumerable<TEntity>类型的返回值，明白的同学都知道，这相当于把整个表的数据都加载到内存中，问题很严重，设计者却不知道。
诸如此类，各种奇葩的查询操作层出不穷，这些操作或者破坏了EF数据查询原有的灵活性，或者画蛇添足。
其实，这么多失误的原因只有一个，设计者忘记了EF是ORM，把EF当作ado.net来使用了。只要记着EF是ORM，以上这些功能已经实现了，就不要去重复实现了。那么以上的问题就非常好解决了，只要：
在数据操作Repository接口中把EF的DbSet<TEntity>开放成一个只读的IQueryable<TEntity>类型的属性提供给业务层作为数据查询的数据源
就可以了。这个数据源是只读的，并且类型是IQueryable<T>，就保证了它只能作为数据查询的数据源，而不像开放了DbSet<T>类型那样可以在业务层中调用EF的内部方法进行增、删、改等操作。另外IQueryable<T>类型保持了EF原有的查询自由性与灵活性，简单明了。这个数据集还可以传递到业务层的各个层次，以实现在哪需要数据就在哪查的灵活性。
(二) 循环中的查询陷阱
EF的导航属性是延迟加载的，延迟加载的优点就是不用到不加载，一次只加载必要的数据，这减少了每次加载的数据量，但缺点也不言自明：极大的增加了数据库连接的次数，比如如下这么个简单的需求：
输出每个用户拥有的角色数量
根据这个需求，很容易就写出了如下的代码：

遍历所有用户信息，输出每个用户信息中角色（导航属性）的数量。
上面这段代码逻辑很清晰，看似没有什么问题。我们来分析一下代码的执行过程：
132行，从IOC容器中获取用户仓储接口的实例，这没什么问题。
133行，取出所有用户信息（memberRepository.Entities），执行SQL如下：
SELECT [Extent1].[Id] AS [Id], [Extent1].[UserName] AS [UserName], [Extent1].[Password] AS [Password], [Extent1].[NickName] AS [NickName], [Extent1].[Email] AS [Email], [Extent1].[IsDeleted] AS [IsDeleted], [Extent1].[AddDate] AS [AddDate], [Extent1].[Timestamp] AS [Timestamp], [Extent2].[Id] AS [Id1] FROM [dbo].[Members] AS [Extent1] LEFT OUTER JOIN [dbo].[MemberExtends] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Member_Id]

虽然EF生成的SQL有些复杂，但还是没什么问题
3. 136行，就开始有问题了，每次循环都会连接一次数据库，执行一次如下查询（最后一个1是用户编号）：
exec sp_executesql N'SELECT [Extent2].[Id] AS [Id], [Extent2].[Name] AS [Name], [Extent2].[Description] AS [Description], [Extent2].[RoleTypeNum] AS [RoleTypeNum], [Extent2].[IsDeleted] AS [IsDeleted], [Extent2].[AddDate] AS [AddDate], [Extent2].[Timestamp] AS [Timestamp] FROM [dbo].[RoleMembers] AS [Extent1] INNER JOIN [dbo].[Roles] AS [Extent2] ON [Extent1].[Role_Id] = [Extent2].[Id] WHERE [Extent1].[Member_Id] = @EntityKeyValue1',N'@EntityKeyValue1 int',@EntityKeyValue1=1

试想，如果有100个用户，就要连接100次数据库，这么一个简单的需求，连接了101次数据库，还不得让数据库疯掉了。
当然，有同学可以要说，这里用了延迟加载才会多了很多连接数据库的次数，你可以立即加载啊，把Role角色一次性加载进来。好吧，我们来看看立即加载：

143行，在取所有用户信息的时候使用Include方法把与用户关联的所有角色信息也一并查询出来了，这样在循环遍历的时候就不会再连接数据库去查询角色信息了。但是如果看到执行的SQL语句，估计你想死的心情都有了。执行的查询如下：
SELECT [Project1].[Id] AS [Id], [Project1].[UserName] AS [UserName], [Project1].[Password] AS [Password], [Project1].[NickName] AS [NickName], [Project1].[Email] AS [Email], [Project1].[IsDeleted] AS [IsDeleted], [Project1].[AddDate] AS [AddDate], [Project1].[Timestamp] AS [Timestamp], [Project1].[Id1] AS [Id1], [Project1].[C1] AS [C1], [Project1].[Id2] AS [Id2], [Project1].[Name] AS [Name], [Project1].[Description] AS [Description], [Project1].[RoleTypeNum] AS [RoleTypeNum], [Project1].[IsDeleted1] AS [IsDeleted1], [Project1].[AddDate1] AS [AddDate1], [Project1].[Timestamp1] AS [Timestamp1] FROM ( SELECT [Extent1].[Id] AS [Id], [Extent1].[UserName] AS [UserName], [Extent1].[Password] AS [Password], [Extent1].[NickName] AS [NickName], [Extent1].[Email] AS [Email], [Extent1].[IsDeleted] AS [IsDeleted], [Extent1].[AddDate] AS [AddDate], [Extent1].[Timestamp] AS [Timestamp], [Extent2].[Id] AS [Id1], [Join2].[Id] AS [Id2], [Join2].[Name] AS [Name], [Join2].[Description] AS [Description], [Join2].[RoleTypeNum] AS [RoleTypeNum], [Join2].[IsDeleted] AS [IsDeleted1], [Join2].[AddDate] AS [AddDate1], [Join2].[Timestamp] AS [Timestamp1], CASE WHEN ([Join2].[Member_Id] IS NULL) THEN CAST(NULL AS int) ELSE 1 END AS [C1] FROM [dbo].[Members] AS [Extent1] LEFT OUTER JOIN [dbo].[MemberExtends] AS [Extent2] ON [Extent1].[Id] = [Extent2].[Member_Id] LEFT OUTER JOIN (SELECT [Extent3].[Member_Id] AS [Member_Id], [Extent4].[Id] AS [Id], [Extent4].[Name] AS [Name], [Extent4].[Description] AS [Description], [Extent4].[RoleTypeNum] AS [RoleTypeNum], [Extent4].[IsDeleted] AS [IsDeleted], [Extent4].[AddDate] AS [AddDate], [Extent4].[Timestamp] AS [Timestamp] FROM [dbo].[RoleMembers] AS [Extent3] INNER JOIN [dbo].[Roles] AS [Extent4] ON [Extent4].[Id] = [Extent3].[Role_Id] ) AS [Join2] ON [Extent1].[Id] = [Join2].[Member_Id] ) AS [Project1] ORDER BY [Project1].[Id] ASC, [Project1].[Id1] ASC, [Project1].[C1] ASC

(三) 导航属性的查询陷阱
我们再来回顾一下导航属性的长相（以用户信息中的角色信息为例）：

可以看到，集合类的导航属性是一个ICollection<T>类型的集合，其实现类可以是通常使用List<T>或者HashSet<T>。用了ICollection<T>，就限定了集合类的导航属性是一个内存集合，只要用到这个导航属性，就必须把集合中的所有数据都加载到内存中，才能进行后续操作。比如上面的例子中，我们的需求只是想知道用户拥有角色的数量，原意只是要执行一下SQL的Count语句即可，却想不到EF是把这个集合加载到内存中（上面的语句，是把当前用户的所有角色信息查询出来），再在内存中进行计数，这无形中是一个很大的资源浪费。比如在一个商城系统中，我们想了解一种商品的销量（proct.Orders.Count），那就可能把几万条订单信息都加载到内存中，再进行计数，这将是灾难性的资源消耗。

D. dbfirst和codefirst有什么区别

先分别介绍一下三种方法的联系：
1.Database First是基于已存在的数据库，利用某些工具（如VS提供的EF设计器）创建实体类，数据库对象与实体类的匹配关系等，你也可以手动修改这些自动生成的代码及匹配文件。也就是从一个数据库开始，然后生成实体框架和相应代码。
2.Model First 是先利用某些工具（如VS的EF设计器）设计出可视化的实体数据模型及他们之间的关系，然后再根据这些实体、关系去生成数据库对象及相关代码文件。
3.Code First 这种方式需要先写一些代码，如实体对象，数据关系等，然后根据已有的代码描述，自动创建数据对象。但其实这种方法与Model First是非常类似的。我们自己写的代码，其实就是用代码表示实体模型，而Model First是用可视化的方式描述了实体模型。

下面分析这三种方式的优缺点：
Database-First模式明显性能会差点，但是它很适合初学者，或者是比较急的小型项目。还有一点，我们在做项目时可能不容易体会到它的好处，但如果做数据库结构比较成熟稳定的产品时，我们可以很轻松的使用数据库生成实体模型，从而实现快速开发。
Model-First模式优点是开发人员能够在模型设计完成后，可以利用VS等工具快速生成数据库脚本。缺点是设计模型时完全了解数据库的结构，在模型中手动添加表关系，并且生成的脚本有点不简洁。
Code-First模式优点是性能比较好，且代码较少冗余。不过它的缺点也有很多，由于都是代码编写的，比如更新数据库。

这三种方式各有利弊，使用过程中我们要按实际需求来选择。这些工具的出现和使用，大大提高了开发人员的开发速度，使得数据库、模型等出现了复用、扩展的可能，在应对变化方面也做了足够的工作。这些工具所体现的服务思想更提醒我们要全方位去考虑问题，在产品中做好应对变化的措施。

E. MVC中EF框架下CodeFirst事务处理，从表数据是根据主表主键添加，而主表主键是自动编号

EF Code-Frist本身就是支持事务的。
我们的每一次SaveChanges就是一个事务操作，只需要在所有更改都完成后，调用这个方法就可以了。
如果你不愿意，网上还有人给出了手动的开启事务的代码（我没有测试过）：

DbConnection con = ((IObjectContextAdapter)ctx).ObjectContext.Connection;
con.Open();
using (var tran = con.BeginTransaction())
{
// 这里才是事务中的代码
tran.Commit();
}
con.Close();

以上都是针对一个DbContext，也就是一个数据库的时候，如果操作涉及到多个数据库，还是使用分布式事务操作比较靠谱。

原文链接：http://www.cnblogs.com/youring2/archive/2012/05/23/2514962.html

F. EF code first 怎样创建数据库视图

1. 使用CodeFirst方式创建数据库
我们新建一个控制台项目，项目中添加两个Model:Author和Blog以及DbContext。 DbContext的添加方式如下：
项目上右键->添加->新建项->ADO.NET Entity Data Model->Empty Code First model
项目代码如下：

1 //默认生成的数据表名为类名+字母s，这里使用TableAttribute来指定数据表名为T_Authors
2 [Table("T_Authors")]
3 public class Author
4 {
5 public int Id { set; get; }
6 public string Name { set; get; }
7 /*
8 此处定义了Blog类型的属性，所以要确保Blog类中至少要有一个表示主键的字段，即public int Id { set; get; }。
否则在生成数据表时会报错："EntityType 'Blog' has no key defined. Define the key for this EntityType.
9 Blogs: EntityType: EntitySet 'Blogs' is based on type 'Blog' that has no keys defined."
10 */
11 public virtual ICollection<Blog> Blogs { set; get; }
12 }
13
14 [Table("T_Blogs")]
15 public class Blog
16 {
17 public int Id { set; get; }
18 public string Title { set; get; }
19 public DateTime Time { set; get; }
20 public int AuthorId { set; get; }
21 public virtual Author Author { set; get; }
22 }
23
24 public class MyDbContext: DbContext
25 {
26 public MyDbContext()
27 : base("name=MyDbContext")
28 {
29 }
30 //DbContext会根据配置文件中connectionStrings指定的数据库名称来建立数据库
31 //DbContext根据DbSet属性的类型来创建数据表，这里指定了Author类型的属性，所以会生成T_Authors数据表
32 public virtual DbSet<Author> Authors { set; get; }
33 }

CodeFirst方式会根据配置文件中的配置生成数据库，这里小编使用的是MYSQL数据库，配置文件如下：

1 <!--EF for MYSQL-->
2 <entityFramework codeConfigurationType="MySql.Data.Entity.MySqlEFConfiguration, MySql.Data.Entity.EF6">
3 <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
4 <providers>
5 <provider invariantName="MySql.Data.MySqlClient" type="MySql.Data.MySqlClient.MySqlProviderServices, MySql.Data.Entity.EF6" />
6 </providers>
7 </entityFramework>
8 <connectionStrings>
9 <add name="MyDbContext" connectionString="server=localhost;port=3306;database=EF;uid=root;password=root" providerName="System.Data.MySqlClient" />
10 </connectionStrings>

PS:小编使用的是EF6和MYSQL数据库，所以要在项目中添加对Mysql.Data.Entity.EF6以及EntityFrameword 6.0的引用。
到此，我们已经完成生成数据库的工作，接下来在Main方法中写两行代码：
1 using (var db = new ManagerDb())
2 {
3 db.Authors.Add(new Author() { Name = "xfh" });
4 db.SaveChanges();
5 }

G. ASP.NET MVC的code first数据库与SQL数据库有什么不同

Code First是Entity Framework提供的一种新的编程模型。通过Code First我们可以在还没有建立数据库的情况下就开始编码，然后通过代码来生成数据库。
SQL数据库即SQLServer数据,SQL Server 是Microsoft 公司推出的关系型数据库管理系统。具有使用方便可伸缩性好与相关软件集成程度高等优点，可跨越从运行Microsoft Windows 98 的膝上型电脑到运行Microsoft Windows 2012 的大型多处理器的服务器等多种平台使用。

H. 什么是代码优先（Code First）求大神指导啊。

CodeFirst是EntityFramework的一种技术手段，因为传统编程方式都是先建立数据库，然后根据数据库模型为应用程序建模，再进行开发；CodeFirst从字面上理解就是代码先行，先在程序中建立要映射到数据库的实体结构，然后EntityFramework可以根据实体结构生成所对应的数据库。

I. EF通过数据库生成code first实体，数据库中不添加外键关系，实体类中如何配置关联关系

你是想数据库不要外键 但是实体要导航属性吧

需求蛮奇特的

1. 你实体也不加导航属性 需要关联数据的时候用 JOIN 查询

2. 重新EF接口 在生成数据库的时候 只解释生成关系