EntityFramework优缺点

高层视图：

改变在现有系统使用EntityFramework的优势是什么？

• All -in-1框架的类映射表，需要编写映射代码, 并且是很难维护的。
• 可维护性，易于理解的代码，无需创造大的数据访问层。
• 提供LINQ查询数据库，这需要从初级开发人员不太了解SQL。
• EF可以用作用于数据服务和OData Service的基础设施。

什么的情况下，不建议使用EF呢?

• 实时的应用程序。
• 只能通过存储过程访问数据库。 EF的优势是：跟踪实体状态Change时，不仅仅在存储过程上.（即使EF确实对存储过程支持有限的）。
• 频繁插入操作（Insert）,  并且EF不支持大数据Bulk 插入。
• 频繁更新操作，更新的目标主要是当多行（用一个单值）
   例如：UPDATE 表名 SET ColumA = 10 Where ColumnB =？
   这种更新操作更好的使用的ExecuteNonQuery（也可从Context上下文或直接从Ado.Net）。
• 反范式的表设计和高性能查询。 EF产生查询，他们是难以维护的，它并不能很好地支持映射到不规范的表。

• 对程序有非常的性能要求, 需要对每个查询进行监控.

我们要在加载所有数据到内存中，建议使用实体框架？ 我们应该期待什么样的问题呢？

• 加载的所有实体将需要许多查询和大量的时间。
• 内存开销。
• 会有延迟，因为EF需要跟踪实体的变化的和大Collection对象的处理。
• EF的Context上下文不是线程安全的，你不应该在整个Service上使用一个Context上下文。
• 如果你打算这样做，使用EF加载实体，但并不管理它们. (Detach the entities从context)。
• 不使用的上下文Context对象作为一个缓存对象（用于分布式的情况下).   它不是线程安全的，有一些开支和不遵循分散关注(Separation of Concern)的设计。 更好的办法是设计缓存API，如AppFabric缓存。

技术层面：

内存泄漏：

我们有这样一个场景，每10秒我们打开Context上下文获取一个单表，并关闭它。 “using (entities context = new entities(_connection)) {… ”

经过一段几个小时，这引起了内存泄漏。
• 我建议你检查内存泄漏，以确保它是从EF是根源。 EF是一个开源的，所以现在可以报告任何内存泄漏并修正它。
• 使用Profiler的VMMap，以便跟踪泄漏的源头。

在这种情况下，我们应该保持Context一直打开？

• 这其实并不重要，因为查询仍然会执行。 然而，这是最好关闭Context下，所以缓存的实体将垃圾回收，否则Context和缓存的实体将在GC中升级到第二代，并且会被困在那里的持续一段时间。
• 不要为WCF每个请求创建一个Context上下文对象。
• 推荐的做法是为每次操作创建的Context对象，因为实体Item一旦被被添加到数据库后就已经过时了，可能会导致数据损坏或重复的Item

EDMX的大小有影响吗？

• EDMX影响的大小，因为所有的EDMX数据加载到内存中创建Context上下文。
• EDMX被加载到内存中，解析与映射在AppDomain中创建和缓存。 您可以关闭并重新打开Context，它没有影响已缓存EDMX映射。

非常多的表

如果所有的表放在单个的EDMX或分别存放于几个EDMX文件之间？

如何能管理的EDMX中大量的实体？ 例如，如何可以找到它们？

在设计器中修改一个特定的表？

• 如果拆分之间edmx文件，你可以不连接实体的导航性能。
  你应该建立自己的模型，根据您的实体模型设计 - 如果你有一组是独立的实体，他们可以在不同的EDMX模型。
   EDMX文件处理数百个实体类型。 如果实体类型的数量超过1000家，我会考虑到的几个Edmxs（分开和重新审视自己的实体模型设计，因为成千上万的实体类型的一个系统似乎太多）。
• 在VS 2012，以设计器的增强分解功能和着色等，请参阅以下链接。
• EF设计器有一些改进，如着色区分实体组的实体。
   也有第三方实体的设计器，可能会得到更好的用户体验。
   请记住 - EF是一个开源的，你可以给他们的要求，甚至贡献自己的增加，所以在EDMX设计器探索很有趣的。
• 你应该按每个域/服务来拆分edmx文件到不同EDMX文件。

表之间关系
 

Lazy与No Lazy模式？
• 在分布式情况下Lazy代码是魔鬼。
• 如果他们需要一组表中的数据，然后使用Include，否则，你可以使用Lazy Load模式

“Include”命令加载整个表或ObjectSet原始记录？
• Include加载是相关实体的列。 EF不使用 * 查询.

如何使用EF执行批量插入/更新操作？
• 做不到这一点，你需要使用原始的SQL语句来实现。

当一个实体被标记为已修改，EF更新的所有列？
• 它不更新所有的列，除非你正在使用分布式的应用程序与Self-Tracking。 “正常”实现下EF只更新修改列。 Self-Tracking不跟踪的已更新的属性，它标志着的所有属性已更新。 您可以编辑Self-Tracking，并修复它，如果需要的话。
• 您可以附加一个SP以实现自定义的逻辑。
• 您可以更改T4模板的文件，在Self-Tracking下以保持所有原始值。

整个RAW更新的开销大么？
• 大多数DB重新计算索引。 这是一个问题关系到DBA。

当我们使用EF为700-800KB的XML文件来更新XML列，我们收到了有关SQL Server的tempdb一个异常。 什么造成的吗？
• 可能涉及到数据库如何用临时表来更新XML的内容。

   应该和DBA检查你的数据库，你也许需要增加您的tempdb数据库的大小。
• 在一般情况下, 大的对象，如XML使在GC的Large Object Heap内存的压力，你应该考虑迁移到.NET 4.5版本的GC大型对象堆碎片整理特性。
• 你可以考虑来存储XML为byte []，它可以被压缩（XML不是一种非常经济的格式）。

使用EF与ADO.Net的开销？
• DataReader的结果变换到对象的开销，从LINQ编译SQL查询的开销。

   您将有相同的开销，甚至更多，如果您尝试建立你自己的ORM框架。 不这样做！
• 抽象层的开销, 它取决于他们用EF所做的事情。
• 一般而言，您应该组合替代继承，避免它有一个更大的开销。

原先用的是三层架构中ADO.NET做底层开发，纯手工sql语句拼装。后来遇到一个MVC+EF项目，体会到了EF的强大性。

它是微软封装好一种ADO.NET数据实体模型，将数据库结构以ORM模式映射到应用程序中。

优点：

1.简洁的Linq to Sql语句大大提高了开发人员的效率，不要再写复杂的sql语句；

2.不再需要再管应用程序如何去连接数据库；

3.EF可以用作用于数据服务和OData Service的基础设施；

缺点：

1.由于linq语句编译之后就是sql，对于这种自动生成的sql语句无法控制；

2.EF的运行机制会消耗大量内存，大大降低了程序运行效率，从而导致降低了用户在客户端的体验效果；

3.一旦数据结构发生变化，需要更新EF数据model；有时还可能会出现找不到更新过的实体类这种情况；