我在我的新网络应用程序中采用了EF（开箱即用）。
这个应用程序确实涉及对db活动的一些操作，并涉及大约30个或更多表。
我的观点是，这不是一个简单的学校项目，EF通常适合大多数需求。
随着我开发此应用程序的进一步发展，我发现EF非常有限或禁止正确/良好的数据库设计（特别是在术语性能方面）
1）包括
我在查询部分遇到Include功能。许多数据缺失是由于缺少包含设置。
我投入的东西越多，我就越担心简单的数据检索会获得比某些功能更多的东西。
2）验证
我正在采用Fluent Validation来满足这种需求，因为我更喜欢访问者模式，而不需要对数据代码本身进行直接的代码更改。
但是当我进行子类化时，我遇到了更多挑战，我需要锻炼验证能够尊重OOP简单的东西。我管理它，虽然更复杂和某些我真的不喜欢它的实现。我相信这个子类验证问题也发生在DataAnnotation中。
3）交易
现在，我需要合并适当的数据库事务处理控制，我发现EF缺少这个，如果我错了，请纠正我。
我曾经使用Enterprise组件（很久以前的.NET中的COM +），我在EF中找不到正确的（或缺少它）事务实现。
我还在努力......
结论）
我开始意识到EF在我的编码中唯一帮助我的是数据/实体代码生成，这是许多其他工具/框架的共同特征。
我想放弃这个EF，切换回EF时代之前的方法，采用存储过程，仍然是代码生成的表类（但不是EF或DBML）。
我可以不用SQL LINQ，因为我在过去的性能问题上遇到了很多挑战。
我喜欢你的意见，我应该坚持并坚持EF，无论出于什么原因，我的简单头脑可以感知到，除了这个ORM，它几乎没有真正的工作。
你看过Dapper了吗？ Dapper是一种超快速的微型ORM。它是由Stackoverflow人员（Sam Saffron）开发的，他们在这个网站上广泛使用它，因为你提到的原因 - 性能和速度。链接在这里：
https://github.com/StackExchange/dapper-dot-net。
我们放弃了EF，我们只使用Dapper。结合其他社区开发的Dapper扩展，如Dapper.SimpleCRUD和Dapper.SimpleCRUD.ModelGenerator，我们可以从数据库中快速生成POCO，同时保留Dapper优于EF的所有优势。总的来说，你将编写更多的代码，但Dapper的速度几乎相当于使用ADO.NET的SqlDataReader。这是SimpleCRUD的链接：
https://github.com/ericdc1/Dapper.SimpleCRUD/
我同意当你超越某个阶段时EF不太有用
如果您的数据库在您的应用程序之外有用，那么为您的企业设计数据库，而不仅仅是您的应用程这就是EF倒下的地方。它不会（不能）将需要的其他玩家的不同观点视为数据库，因此您最终会得到天真的索引和关系。
我的2c（对一个非常复杂的问题的快速反应）：
编写SP（是的，我知道）来管理数据收集，为业务层提供有用的数据集，并允许插入/更新基础表。确保编写有用的数据API，不要只为每个表编写CRUD。这是毫无意义的浪费时间。
使用EF挂钩这些SP。 EF生成有用的数据类，为您提供事务包装器和其他一些有用的位和bob。
请享用！
没有任何工具可以做任何事情 - 随着情况的出现挑选。
我有自己的数据访问层使用服务堆栈的ORMlite和toptensoftware的PetaPoco创建。
ORMlite：
1）从C＃类创建表，包括关系，约束等。（CodeFirst）
2）可以做插入，删除，更新等。
示例 - 创建表：Employee.EnsureTable（）
Petapoco：
提供者很棒的SQL包装类，我使用它而不是linq
例如：sql.Select（“FirstName，LastName”）。From（“Employee”）。其中（“ID = @ 0”，100）.AND（“Active = @ 0”，1）
我比LINQ更喜欢上面的风格。这也支持Joins（酷吧？）
目前ORM lite不是免费的。但是你可以获得免费的旧版本。
例：
//Creating Entity Class
public class Employee:DatabaseEntity<Employee>
{
//Define properties
}
//DatabaseEntity is my own base class which provides many helper methods from ORM lite and Petapoco, including many static methods eg:EnsureTable()
//Creating Table
Employee.EnsureTable()
//Adding new entity
Employee e=new Employee();
e.FirstName="Chola"
e.LastName="Raja"
e.Active=true
e.Save()
//Find an employee
e=Employee.FirstOrDefault(x=>x.ID==101 && x.Active==true);
//OR
e=Employee.QuerySingle(sql.Select("FirstName,LastName").From("Employee").Where("ID=@0",100).AND("Active=@0",1))
//update
e.LastName="Raja"
e.Save()
//Delete a entity
e.Delete()
//Transaction
e.AssignProject(project1) //this method could do many operation on many entities using Transaction scope
注意： 我无法从我的项目中提取代码。但是您可以根据您的要求创建自己的Base类
说实话，我几年前仍然建议任何.net / sql新手与EF一起使用因为linq语法，它看起来很性感......
但这就是它的全部。老实说，没有其他任何你可以从EF获得。
我知道编写C＃而不是SQL的诱惑在开始时听起来非常有用，但实际上并非如此。没有机器生成的sql可以击败手工制作的SQl野兽，你最终会在一天结束时:)
除此之外，EF只是吃内存，这是Web服务器的内存和CPU，在大多数情况下，我认为，但不确定。尽管如此，它在性能和内存方面消耗了更多的资源。
而且我完全厌倦了沉重的20磅重的edmx模型GUI。每张桌子+1磅:)减少这么多时间让edmx与实际的DB保持同步，毕竟是什么原因？谁说你需要VS中所有那些色彩鲜艳的图标，真的吗？所有这些东西只有一个而且唯一的原因 - 使linq-to-entities成为可能。为了地狱，我只是发现原始的SQL看起来绝不是好看或酷。
所以，我自己前一段时间做出了一个决定 - 我的个人项目没有EF。
没有笨重的东西，生活很容易，当你采取和轻松。