我在新的互联网应用程序中采用了EF（开箱即用的.NET 4.5）。
这个应用程序确实涉及到对db活动的一些操作，并且涉及大约30个或更多的表。
我的观点是，这不是一个简单的学校项目，EF通常适合大多数需求。
在我进一步开发这个应用程序的过程中，我发现EF对于正确/良好的数据库设计（尤其是在性能方面）来说非常有限或令人望而却步
1） 包括
我在查询部分遇到了Include功能。许多数据丢失是由于缺少包含设置。
我在这个东西上投入的越多，我就越担心一个简单的数据检索会得到比我在某些功能中需要的更多的东西。
2） 验证
我采用Fluent Validation来满足这一需求，因为我更喜欢访问者模式，在这种模式下，不需要对数据代码本身进行直接的代码更改。
但当我进行子类化时，我遇到了更多的挑战，我需要锻炼验证能力，以尊重OOP简单的东西。我管理了它，尽管它的实现更加复杂，而且有些事情我真的不喜欢。我相信这个子类验证问题也发生在DataAnnotation中。
3） 交易
现在，我需要结合适当的db交易控制，我发现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生成有用的数据类，为您提供事务包装器和其他一些有用的位&波波头。
享受吧！
没有一个工具可以做所有的事情-pick&根据情况选择。
我使用服务堆栈的ORMlite和toptensoftware的PetaPoco创建了自己的数据访问层。
ORMlite:
1） 从C#类创建表，包括关系、约束等。（CodeFirst）
2） 可以进行插入、删除、更新等操作。
示例-创建表：Employee.EnsureTable（）
Petapoco:
提供了很棒的SQL包装类，我用它代替linq
例如：sql。选择（"FirstName，LastName"）。From（"Employee"）。Where（"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
注意：我无法从项目中提取代码。但是您可以根据自己的需求创建自己的基类
老实说，几年前我仍然建议任何新来的.net/sql使用EF，因为linq语法，它看起来很性感。。。但仅此而已。老实说，EF不会给你带来任何其他好处。
我知道写C#而不是SQL的诱惑在一开始听起来可能很有用，但事实并非如此。任何机器生成的sql都无法击败手工制作的sql野兽：）
除此之外，EF只是吃掉了内存，也就是网络服务器的内存和CPU，嗯，在大多数情况下，我认为，但不确定。尽管如此，它在性能和内存方面消耗了更多的资源。
我完全受够了20磅重的edmx模型GUI+每张表1英镑：）浪费了这么多时间来保持edmx与实际DB的同步，到底是什么原因？谁说你在VS中需要所有这些五颜六色的图标？所有这些东西都存在，只是为了一个也是唯一的原因——使linq到实体成为可能。见鬼去吧，我只是发现原始SQL看起来一点也不差。
所以，我自己不久前做出了一个决定——我的个人项目没有EF。没有沉重的东西，生活很容易，当你拿着它，让它变得容易。