2009年2月 .NET技术大版内专家分月排行榜第三
2013年4月 VC/MFC大版内专家分月排行榜第一2007年7月 VC/MFC大版内专家分月排行榜第一2007年5月 VC/MFC大版内专家分月排行榜第一2007年4月 VC/MFC大版内专家分月排行榜第一2007年3月 VC/MFC大版内专家分月排行榜第一
2013年3月 VC/MFC大版内专家分月排行榜第二2013年2月 VC/MFC大版内专家分月排行榜第二2008年8月 VC/MFC大版内专家分月排行榜第二2008年7月 VC/MFC大版内专家分月排行榜第二2007年9月 VC/MFC大版内专家分月排行榜第二2007年8月 VC/MFC大版内专家分月排行榜第二2005年12月 VC/MFC大版内专家分月排行榜第二2005年10月 VC/MFC大版内专家分月排行榜第二
本帖子已过去太久远了，不再提供回复功能。3977人阅读
.NET（20）
这个示例同时包含了一对多，如下4个类：
部门类&&& Department
员工类&&& Employee
项目类&&& Project
部门和员工是一对多关系
项目和员工是多对多关系
代码如下：
using System.Collections.G
using System.L
using System.T
ponentModel.DataA
namespace EFLabCodeFirst
[Table(&Departs&)]
public class Department
[DatabaseGenerated( ponentModel.DataAnnotations.DatabaseGeneratedOption.None)]
[Column(&DEPART_ID&)]
[MaxLength(6)]
public string DepartID { }
[Column(&DEPART_NAME&)]
[MaxLength(16)]
public string DepartName { }
[Column(&DEPART_BUILD_TIME&)]
public DateTime? DepartBuildTime { }
/// &summary&
/// 一个部门有多个员工
/// &/summary&
public virtual ICollection&Employee& Employees{}
using System.Collections.G
using System.L
using System.T
ponentModel.DataA
namespace EFLabCodeFirst
/// &summary&
/// 项目,一个项目可以有多个员工参与
/// &/summary&
[Table(&Projects&)]
public class Project
/// &summary&
/// 项目编号,按照Code First约定会生成标识列
/// &/summary&
public int? ProjectId { }
/// &summary&
/// 项目名称
/// &/summary&
[Required]
[MaxLength(32)]
public string ProjectName { }
/// &summary&
/// 项目启动时间
/// &/summary&
public DateTime? ProjectStartTime { }
/// &summary&
/// 参与此项目的员工的集合
/// &/summary&
public virtual ICollection&Employee& Employees { }
using System.Collections.G
using System.L
using System.T
ponentModel.DataA
namespace EFLabCodeFirst
/// &summary&
/// 员工,一个员工可以参与多个项目
/// &/summary&
[Table(&Employees&)]
public class Employee
[DatabaseGenerated( ponentModel.DataAnnotations.DatabaseGeneratedOption.None)]
[MaxLength(8)]
public string EmployeeID { }
[Column(&DEPART_ID&)]
[MaxLength(6)]
public string DepartID { }
/// &summary&
/// 一个员工属于一个部门
/// &/summary&
[ForeignKey(&DepartID&)]
[InverseProperty(&Employees&)]
public virtual Department Department {}
[Required]
[MaxLength(8)]
public string EmployeeName { }
public int? EmployeeAge { }
/// &summary&
/// 当前员工参与的项目的集合
/// &/summary&
public virtual ICollection&Project& Projects { }
CodeFirstDbContext类：
using System.Collections.G
using System.L
using System.T
using System.Data.E
using System.Data.O
ponentModel.DataA
namespace EFLabCodeFirst
/// &summary&
/// 自定义类必须继承自DbContext,DbContext来自EF4.1的EntiyFramework.dll这个程序集
/// &/summary&
public class CodeFirstDbContext:DbContext
public DbSet&GameUser& GameUsers { }
public DbSet&GameRole& GameRoles { }
public DbSet&Project& Projects { }
public DbSet&Employee& Employees { }
public CodeFirstDbContext()
public CodeFirstDbContext(string conn):base(conn)
//是否启用延迟加载:
延迟加载（Lazy Loading）：获取实体时不会加载其导航属性，一旦用到导航属性就会自动加载
直接加载（Eager loading）：通过 Include 之类的方法显示加载导航属性，获取实体时会即时加载通过 Include 指定的导航属性
this.Configuration.LazyLoadingEnabled =
this.Configuration.AutoDetectChangesEnabled =
//自动监测变化，默认值为 true
/// &summary&
/// 实体到数据库结构的映射是通过默认的约定来进行的，如果需要修改的话，有两种方式，分别是：Data Annotations 和 Fluent API
以下示范通过 Fluent API 来修改实体到数据库结构的映射
/// &/summary&
/// &param name=&modelBuilder&&&/param&
protected override void OnModelCreating(DbModelBuilder modelBuilder)
modelBuilder.Entity&GameRole&()
.Property(p =& p.GameRoleID)
.HasColumnName(&GameRoleID&)//设置映射的表字段名
.HasDatabaseGeneratedOption(DatabaseGeneratedOption.Identity)//设置映射字段的值生成方式为标识列
.IsRequired();//设置字段值是必须的
modelBuilder.Entity&GameRole&()
.Property(p =& p.GameRoleName)
.HasMaxLength(32)//字段长度
.IsOptional()//字段的值可以为空
.IsUnicode()//字段值类型为nvarchar
.IsVariableLength();//字段长度是可变的
modelBuilder.Entity&Project&()//注册一个实体类型为模型的一部分,返回的对象用于配置这个实体
.HasMany&Employee&(p =& p.Employees)//从这个实体类型配置一个多关系[此处表明一个项目拥有一个员工对象的集合]
.WithMany(e =& e.Projects)//配置这个多对多关系的另一端,另一端通过导航属性能够被访问(此处表明一个员工拥有一个项目对象的集合)
.Map(m =& {
//配置用于存储关系的外键字段和表
m.MapLeftKey(&ProjectID&);//引用的左表字段
m.MapRightKey(&EmployeeID&);//引用的右表字段
m.ToTable(&ProjectEmployee&);//中间表
base.OnModelCreating(modelBuilder);
测试代码：
static void Demo7()
using(CodeFirstDbContext db = new CodeFirstDbContext())
//添加项目对象
db.Projects.Add(new Project { ProjectName = &CRM系统&, ProjectStartTime = DateTime.Now });
db.Projects.Add(new Project { ProjectName = &HR系统&,ProjectStartTime=DateTime.Now});
db.Projects.Add(new Project { ProjectName= &数字触摸屏系统&,ProjectStartTime=DateTime.Now });
//保存项目对象
db.SaveChanges();
Project p1 = db.Projects.Where(d =& d.ProjectName == &CRM系统&).FirstOrDefault();
db.Entry(p1).Reload();//预加载项目对象
//添加员工对象
p1.Employees.Add(new Employee { EmployeeID = &E001&,EmployeeName=&刘兵&,EmployeeAge=22});
p1.Employees.Add(new Employee { EmployeeID = &E002&, EmployeeName = &王雪梅&, EmployeeAge = 30 });
p1.Employees.Add(new Employee { EmployeeID = &E003&, EmployeeName = &张一山&, EmployeeAge = 22 });
//保存员工对象及项目对象和员工对象的关系
db.SaveChanges();
App.config文件配置：
&?xml version=&1.0& encoding=&utf-8&?&
&configuration&
&connectionStrings&
&add name=&CodeFirstDbContext& connectionString=&Server=.\Database=CodeFintegrated security=true& providerName=&System.Data.SqlClient&/&
&/connectionStrings&
&/configuration&
生成的数据结构：
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：277362次
积分：4822
积分：4822
排名：第5390名
原创：198篇
转载：35篇
评论：43条
(1)(3)(1)(1)(1)(1)(1)(2)(1)(1)(2)(1)(1)(1)(7)(1)(3)(2)(3)(9)(5)(1)(3)(5)(2)(4)(9)(6)(2)(12)(6)(4)(12)(4)(4)(11)(10)(11)(37)(3)(10)(1)(2)(3)(5)(1)(5)(12)8天掌握EF的Code First开发之Entity Framework介绍-爱编程
8天掌握EF的Code First开发之Entity Framework介绍
Entity Framework概要
Entity Framework是微软的Object Relational Mapper(对象关系映射器)，也就是我们平常说的ORM，它可以让应用程序开发者将关系型数据作为业务模型来使用，也消除了开发者为数据访问编写的绝大多数管道代码的需要(比如使用ADO.NET)。Entity Framework提供了一个综合的、基于模型的系统，通过摆脱为所有的领域模型编写相似的数据访问代码，使得开发者创建数据访问层是如此之简单。Entity Framework的首发版本是EF3.5，是伴随着.Net Framework 3.5 SP1和VS 2008 SP1一同发布的。从那之后，EF已经进化了很多很多，当前版本是6.1.3
Entity Framework通过开启数据访问和将数据表示为概念化模型（即一系列的实体类和关系）减轻了创建数据访问层的任务。应用程序可以执行基本的CRUD操作，以及轻松地管理实体间的一对一，一对多和多对多关系。
下面是使用Entity Framework的一些好处：
因为开发者不需要为数据访问编写所有需要的ADO.NET管道代码，因此这可以节省很多开发时间。
我们可以使用更高级的语言（例如C#）来编写所有的数据访问逻辑而不是编写SQL查询和存储过程。
因为数据库表没有高级的关系（如继承），然而领域实体是可以有的，所以业务模型（也就是概念模型）可以使用实体间的关系来适配应用领域。
底层的数据存储可以相对轻松地被取代，因为所有的数据访问逻辑都呈现在应用层而不是数据层。
现在通过一张图看一下EF的架构：
从这张图上可以看到，EF是建立在ADO.NET框架之上的，它下面仍旧使用了ADO.NET方法和类来执行数据操作。
几乎所有的商业软件都要存储数据，多年来，Relational Database Management System（RDBMS）一直是开发者寻求的数据存储。ORM是允许开发者使用面向对象的编程语言访问RDBMS数据的一系列技术。可用的RDBMS包括SQL Server, Oracle, DB2, MySQL等等。这些数据库系统有一些共性。每个数据库系统都支持一个或多个数据库。数据库都包含数据表，每个表都以表格的形式存储数据，并且被分成了列和行。多个表中的数据行可能相互关联。比如，一个订单Order表中的Id可能存储在一个流水表Transaction中。
过去，在像EF这样的工具出现之前，开发者都是在软件代码内部嵌套的sql语句，这是因为编程语言不能原生理解Sql。比如，要从数据库中检索数据，然后将结果作为对象操作，必须使用ADO.NET要写相当数量的代码才行。具体来说，先定义一个存储person的类，然后打开数据库连接，创建具有查询文本的命令，再执行该命令的reader，然后对该reader的结果进行迭代，最后再使用来自reader的数据填充Person类的实例。你会看到，这里包含了很多步骤，而且更重要的是，这样写的代码维护成本很高。比如，数据库中改了一个列名，这样还要去代码中进行相应更改，否则运行时就会抛出异常。此外，我们数据库中存储的是标量值数据（int,string等），但我们的目标是一个对象或者对象图。这样看来，这种访问数据的方式有很多问题。
首先，RDBMS的列类型和.Net类型之间有类型失配；其次，存储和目标之间也不匹配，前者是标量值的集合，后者是具有属性的对象。更糟糕的是，键入我们的person对象有一个更复杂的属性List Phones，该属性代表其他表的集合。这些问题在OOP和关系数据库中被称为“阻抗失配”（impedance mismatch）。
ORM这些工具出现的原因就是为了解决这种失配问题。ORM工具将存储在数据表中的数据表示为对象，这比起传统的代码有很多优势：
它们使用原生.net类型暴露数据，使用简单的属性暴露相关的数据，提供编译时检查。
最后，在后面会看到，你会写更少的代码。更少的代码意味着更少的bugs，不是吗？：）
Entity Framework简史
多年来，有许多ORM工具进入市场，有开源的，也有商业的。微软也开发了自己的ORM工具。第一个是内置于.Net 3.5的LINQ to SQL。该ORM仅支持
SQL Server和SQL Server Compact。2008年第一次发布的Entity Framework是第二次尝试，相较于LINQ to SQL有很多优点。首先，有自己的provider架构，因此对于所有的关系数据库引擎都是开放的，而不仅仅是SQL Server。现在所有的主要RDBMS都有Entity Framework provider。
Entity Framework经历了很多版本。
第一版只支持Database First。这意味着你要将设计器指向一个已存在的数据库，然后就会生成一个包含数据库和表抽象的代码。除了代码之外，还会创建一个EDMX文件，该XML文件包含了实体数据模型（因此你也就知道了EDMX的意思了Entity Data Model Xml）。它包括三个模型：逻辑，存储和映射。逻辑模型（有时也叫概念模型）就是使用C#进行编码的那个，存储模型描述了数据是如何存储到数据库中的，映射模型提供了逻辑模型和存储模型之间的映射。如果你在数据库中更改了东西，那么你也要更新生成的模型，C#代码也要再次生成。映射模型有一个基于ObjectContext的类，该类有数据库中每张表的集合属性，每个集合都是一个泛型集合，集合中的元素类型是从EF中的一个基类中继承的。每个类都有属性和相应的数据表中的列对应。
第二版，也就是EF4，也开始支持Model-First了。这样 ，我们就可以使用设计面板创建实体类，然后设计器会产成SQL脚本来生成数据库。对于这种方法，仍会生成EDMX文件，最终的结果是和Database First是相同的。
最后，EF的Code First在版本4.1中引入。Code First不需要EDMX文件了，每个实体也不需要从EF的基类中继承了。这样，代码变得更加容易测试。这种方法也不需要依赖设计器了，你只需要编写类就行，而且它们会自动地映射到数据库中的表。当前的EF 6.1.3中的Code First已经相当强大了。
Entity Framework具有的能力
EF对于微软开发者可以做很多事情。
首先，它可以将数据库暴露成对象的集合，这是通过利用很多关键的类完成的。前提是你要了解DbContext，这个类是EF Code First的核心，在高层次上是数据库抽象。数据库包含了表，每个表又包含了行和列。DbContext有泛型集合属性，每个属性的类型是DbSet&TRowType&对应于每个表。集合中的每个对象指的是一个实体，代表相应表中的一行。数据表中的列是定义在TRowType类中的属性。
一旦这个结构布局好了，那么你就能够通过LINQ查询来查询底层的数据库了。如果你将一个全新的TRowType类的实例添加到父集合中，然后使用DbContext API保存更改，那么这个新的对象就会变成相应表中的一行，该对象的每个属性的值就会变成该行相应的列值。此外，EF有能力表示其他的数据库工件，比如存储过程和函数。数据库结构的进化是很重要的一个问题，在大多数情况，随着应用程序的变化，你需要添加列和表，EF是通过Migration（迁移）功能来解决这个问题的。这个能力允许你通过C#代码更改数据库结构，除了添加和删除表和列之外，还可以添加索引。Migration可以没有数据损失地进化数据库模式。你将会看到，EF会暴露你需要使用C#访问的一切数据而不需要编写SQL，并且像对待你整个应用程序代码的一部分来对待数据库。你可以将migration代码迁入到源代码控制系统（Git/SVN）中，因为它也是C#代码！
Entity Framework的架构
EF构建在provider架构之上。当开发者使用C#创建一个LINQ查询时，EF框架引擎会连接一个provider，将它转换成实际的SQL语句，最后发往数据库。任何给定的provider都是连接Entity Framework和一个特定的RDBMS的桥梁。一旦该provider执行了最终的SQL命令，结果就被EF物质化到.NET对象中。Data reader就是为了这个目的。理解EF构建于ADO.NET之上非常重要，因此，EF也使用了诸如connection，command，和data reader的概念。谈到数据持久化，也就是插入，更新和删除功能，插入时，开发者将一个实体类的实例添加到数据库上下文中。相似地，之前添加到上下文中的实例被标记为changed或deleted，就会产生对数据库即将执行更新和删除的语句。EF会检查上下文中的每个对象，再次使用provider来创建RDBMS特定的insert,update,或delete命令。
Entity Framework建模和持久化
EF依赖概念模型完成工作，首先来理解一下什么是Entity Data Model（EDM）以及EF如何使用它管理数据库操作。
概念数据模型是EF的核心。要使用EF,我们必须创建概念数据模型，即EDM。EDM定义了我们的概念模型类，这些类之间的关系，以及这些模型到数据库模式之间的映射。
一旦创建了EDM,我们就可以对概念模型执行所有的CRUD操作，EF会将所有的这些对象查询翻译成数据库查询（SQL）。一旦这些查询执行了，EF就会将返回的结果转成概念模型对象实例。EF会使用存储在EDM中的映射信息来执行对象查询到SQL查询，以及相关的数据到概念模型的翻译。
一旦EDM准备就绪，我们就可以使用模型对象来执行CRUD操作。要能够执行CRUD操作，我们必须使用ObjectContext类。接下来让我们理解一下这个类。
理解ObjectContext类
一旦我创建了EDM，我就有了应用程序中可以使用的所有的实体。然而，我还需要一个东西来让我在这些实体上执行各种操作。它就是EF中的ObjectContext类。
ObjectContext类是EF中的主要对象。它负责：
管理数据库连接
提供执行CRUD操作的支持
追踪模型的更改，目的在于在数据库中更新模型
ObjectContext类可以理解成管理EDM中所有实体的东西，让我们为这些实体执行所有的数据库操作。当我们想要保存一个新的或者更改的对象到数据库时，我们必须调用ObjectContext类中的SaveChanges方法。
还有另一个类DbContext,它和ObjectContext类很相似。实际上，Dbcontext类就是ObjectContext类的封装类。它是一个更新的API，而且它提供了更好的API来管理数据库连接和执行CRUD操作。
因为DbContext是更好的API，所以我们会使用DbContext来执行所有的数据库操作。
Entity Framework的三种开发风格
Database First:这是一种用于已存在数据库模式的方法。使用这种方法，EDM是从数据库模式中生成的，这种方法最适合于使用了已经存在的数据库的应用。
Code First:这种方法中，所有的领域模型都是以类的形式编写的。这些类会建立我们的EDM，数据库模式会从这些类中创建。这种方法最适合于那些高度以领域为中心并且领域模型类创建优先的应用程序。这里需要的数据库只是为了这些领域模型的持久化机制。
Model First:这种方法和Code First方法很相似，但是这种情况下我们使用了EDM视觉设计器来设计我们的模型。数据库模式和类将会通过这个概念模型生成。该模型将会给我们创建数据库的SQL语句，然后我们可以使用它来创建数据库并连接应用程序。
三种风格的比较
Database First
主要的好处就是：如果数据库已经存在了，那么只需要花一点时间就可以看编写数据访问层。EDM可以从数据库中生成，然后根据需求更改EDM。
一些场景：
对遗留的数据库进行开发
当其他团队的DBA完成了数据库设计时，一旦数据库完成，应用开发就要开始
当要开发数据为中心的应用时，应用领域模型就是数据库本身，数据库会频繁修改来满足新的需求。
Model First
和Database First相似，Model First最终以EDM结束。使用该EDM,我们可以创建概念模型和数据库。使用这种方法的唯一原因就是我们真的想要使用视觉实体设计器。
Code First
Code First对于所有的业务逻辑以类实现，并且数据库只用作这些模型的持久化机制时很有用。
选择Code First的一些原因：
数据库只是作为模型的持久化机制，即数据库中没有逻辑。
完全控制代码，即没有自动生成的模型和上下文代码。
数据库不会手动更改。模型类总是更改，然后数据库基于模型类的更改而更改。
如何选择持久化方法
上面介绍了三种选择，至于选择哪一种，这也是个不大不小的问题，那么请参考下面进行决定：
方法一：工作流决定树
方法二：检查清单
有遗留的数据库或者数据库已经存在
Database First
在开始开发前，我们会获得DBA创建的数据库
Database First
数据库频繁改变，应用程序应该随之改变
Database First
我们想要使用视觉实体设计器来生成数据库和模型类
Model First
我们已有模型类并且只需要数据库保存数据
Code First
我们想要编写所有的模型类，实现这些类，然后考虑数据库存储
Code First
我们不想处理自动生成的类，且更喜欢动手亲自编写
Code First
这一节我们看到了传统的嵌入式sql访问数据的短处，并理解了什么是ORM以及ORM主要解决的问题。同时，我们回顾了一下Entity Framework的历史发展，也看到EF能做什么。我们也简要地看了一下EF的架构。然后理解了什么EDM，ObjectContext，以及它和DbContext的区别和联系。随后我们介绍了EF的三种开发方式（也叫EF工作流）和它们之间的比较，以及使用它们的可能场景，最后介绍了如何选择哪一种方式。
ORM工具解决了下面问题中的哪一个？
RDBMS和.Net Framework类型是相同的。
RDBMS和OOP之间的阻抗失配
学习SQL很困难
在EF中开发者必须编写SQL查询，对吗？
EF使用了哪种技术来将结构的变化应用到数据库中？
Conversions
Migrations
使用EF Code First时，下面哪个重要的类代表了数据库的抽象？
ObjectContext
DataContext
EF只能使用微软数据库工作，如SQL Server，对吗？
点击查看答案默认您已支持本文
RDBMS和OOP编程间的阻抗失配是ORM工具解决的主要问题。ORM使程序员以和任何其他的对象打交道的方式和数据库对话。
不对，在EF中LINQ可以用于创建查询，这样开发者就可以使用C#查询而不是SQL。
Entity Framework Migrations用于脚本化结构的改变，以及将结构的改变应用到数据库，这样就将它从软件的一个版本移动到下一个版本。
DbContext代表数据库的抽象。它有基于集合的属性，该属性表示数据库中的表。
不对。当EF使用provider架构时，它可以使用任何具有provider的数据库工作。此时，所有主要的数据库引擎都支持，如MySQL, DB2, and Oracle。
版权所有 爱编程 (C) Copyright 2012. . All Rights Reserved.
闽ICP备号-3
微信扫一扫关注爱编程，每天为您推送一篇经典技术文章。在群中听人有这种说法。大家认为怎么样呢？
回复讨论(解决方案)
N年前“听”人说手机不成熟&
N+N年前&听&人说电脑不成熟&
N+N+N年前&听&人说&开放&不成熟
N+N+N+N年前&听&人说&全球化&的市场不成熟
和成熟不成熟关系不大，只和数据规模和复杂度有关
还是俺们说烂的一句话“关系数据库表不等于业务对象，业务对象也不等于数据库表”
对象建模本身与数据库关系不大，虽然是可以利用对象模型构建数据库，但是强行划等号，只能在数据规模比较小，复杂度也没那么大的情况下，这两玩意可以近似看成相等
当数据规模和复杂度上升到一定程度后，业务对象就绝不等于数据库表了，当然我说这话绝不是从一般那些博客的人们喜欢矫情的性能上说滴，我说这话是从对象和关系这两家伙的匹配度上说滴。
诚然我们现在已经习惯先对象后库的设计方式，但是你心里真以为你的对象的作用就是去数据库表里查查数据而已？？
如果仅仅把业务对象看做去数据库查查数据，那么可以肯定的说你用啥子玩意都一样，那些东西对你来说和ado.net木有任何区别
EF5&Code&First&&实际项目上使用过后,感觉已经根目录成熟了
Code&First&光见网上有人用。
面试过的公司都是DB&First。
你想想，哪个架构师，技术经理之类的人物会花费大量时间用代码描述数据库关系给程序员服务？
了解，多位都是经验人士。
Code&First&光见网上有人用。
面试过的公司都是DB&First。
你想想，哪个架构师，技术经理之类的人物会花费大量时间用代码描述数据库关系给程序员服务？
这个实在。
用了几个项目，很好用，感觉比Db&First方便
但是没有在特别大的数据下试过
用了几个项目，很好用，感觉比Db&First方便
但是没有在特别大的数据下试过
数据大？是数据量大还是指表特别多呢？两百到三百个表。
code&first技术从最初发布到现在已经有两三年了吧？我这一两年来做的新项目都用这个，不知道楼主说的不成熟是指什么？另外code&first只是一个ORM技术，和数据量大小能有什么关系呢？
在群中听人有这种说法。大家认为怎么样呢？
前期开发&效果好，速度快。&后期改变设计，增加功能比较罗嗦。
个人意见：不是个很优秀orm
code&first适合原型开发，在这个用途下，它是成熟的。另外，ef和ef&codefirst不同，前者的适用场景更大，后者和orm没有什么关系。
后者和orm没有什么关系。
为什么没有关系？
把class类设计，&转化成数据库的表之类的实体，怎么不是orm?
明显项目需要什么就用什么，完全可以两个配合用的吧
用了几个项目，很好用，感觉比Db&First方便
但是没有在特别大的数据下试过
数据大？是数据量大还是指表特别多呢？两百到三百个表。
是指数据量大，表多表少没特别注意，没有遇到过表多表少的问题……
另外code&first只是一个ORM技术，和数据量大小能有什么关系呢？&
在大的数据库会有性能问题
因为在几千万条或数量更高的查询中（尤其是带Join），提高性能的重要方法优化Sql语句结构，制定相应的Index等等
但是经过Orm之后会把原本简单可定制的Sql语句变得复杂化，因为EF的Sql语句都是框架生成的，（除了EF有SqlQuery可以直接跑Sql），要调整生成的Sql语句需要花很大的代价，自动生成的sql会让Index很不好配置
优化性能就是一个很大的问题。
那是否可以添加修改删除使用EF，而查询时使用原生SQL？
和成熟不成熟关系不大，只和数据规模和复杂度有关
还是俺们说烂的一句话“关系数据库表不等于业务对象，业务对象也不等于数据库表”
对象建模本身与数据库关系不大，虽然是可以利用对象模型构建数据库，但是强行划等号，只能在数据规模比较小，复杂度也没那么大的情况下，这两玩意可以近似看成相等
当数据规模和复杂度上升到一定程度后，业务对象就绝不等于数据库表了，当然我说这话绝不是从一般那些博客的人们喜欢矫情的性能上说滴，我说这话是从对象和关系这两家伙的匹配度上说滴。
诚然我们现在已经习惯先对象后库的设计方式，但是你心里真以为你的对象的作用就是去数据库表里查查数据而已？？
对象建模本身与数据库关系不大，虽然是可以利用对象模型构建数据库，但是强行划等号，只能在数据规模比较小，复杂度也没那么大的情况下，这两玩意可以近似看成相等
那是否可以添加修改删除使用EF，而查询时使用原生SQL？
首先从技术上讲,EF的修改还是涉及到查询的
一般都是Context.Find()或者Where（这些更新的对象都会被ChangeTracker在内存中追踪状态，因此还是会被查询出来）
Context.SaveChange()
或者Context.Entry&T&(oldvalue).CurrentValue(newValue)
大多数人用Entity&Framework更新都是这么用的
你说的“而查询时使用原生SQL？”&--&其实Ibatis倒适合做这个事情
但是在设计一个系统数据层，没人希望用两种不同的数据读取方式
那是否可以添加修改删除使用EF，而查询时使用原生SQL？
首先从技术上讲,EF的修改还是涉及到查询的
一般都是Context.Find()或者Where（这些更新的对象都会被ChangeTracker在内存中追踪状态，因此还是会被查询出来）
Context.SaveChange()
或者Context.Entry&T&(oldvalue).CurrentValue(newValue)
大多数人用Entity&Framework更新都是这么用的
你说的“而查询时使用原生SQL？”&--&其实Ibatis倒适合做这个事情
但是在设计一个系统数据层，没人希望用两种不同的数据读取方式
额，其实我指的是复杂查询
code&first技术从最初发布到现在已经有两三年了吧？我这一两年来做的新项目都用这个，不知道楼主说的不成熟是指什么？另外code&first只是一个ORM技术，和数据量大小能有什么关系呢？
吴老师如何用code&first的&&新建实体模型&然后生成数据库表？这么做很鸡肋吧。&我见过的一般都是根据需求设计好表，然后手写fluent&api配置关系，最后用ef做crud的吧
求吴老师分享
code&first技术从最初发布到现在已经有两三年了吧？我这一两年来做的新项目都用这个，不知道楼主说的不成熟是指什么？另外code&first只是一个ORM技术，和数据量大小能有什么关系呢？
吴老师如何用code&first的&&新建实体模型&然后生成数据库表？这么做很鸡肋吧。&我见过的一般都是根据需求设计好表，然后手写fluent&api配置关系，最后用ef做crud的吧
求吴老师分享
你写OOP自然是实体先于关系表，如果流程简单到可以直接写关系表的话，那就不需要用orm
code&first&和&设计器生成的，其实内部都一样。code&first&是通过反射和&fluent&api&来建立映射关系。设计器生成的是通过&xml&来描述。二者最终生成的&sql&都一样。&