我熟悉EF，它看起来很酷。据我所见，它基本上是一个带有额外功能(如缓存、自动连接处理等)的LINQ to SQL。然而，在我看来，EF对于那些直接与模型数据混合的应用程序(~持久性)是有用的。
在编写RESTful web服务的情况下，我们读取和编写JSON格式的对象(例如)。应用程序使用一些数据调用web服务，并返回数据。
这就是为什么我实际上考虑而不是使用EF，因为这对我来说似乎有些过头了。由于我不打算公开实际的模型，我会使用DTO(同时作为web服务调用的输入和输出)。这意味着我无论如何都必须映射到底层模型，这样EF就可以用作LINQ到SQL的包装器。
我缺什么了吗？在编写RESTful web服务时，有什么有用的功能吗？使用EF而不是LINQ to SQL有什么好处吗？
所以这里的逻辑是，您没有通过数据层公开您的实体，所以EF是毫无意义的。
我从不通过业务层公开我的EF实体，只从数据层向下一层。我总是将它们投影到ViewModels和Models，它们只是POCO。我在很多项目中都看到过这种情况。
我很少实际使用实体更改跟踪功能。当GET/POST发生时，仅仅通过更改跟踪来更新POST上的实体是没有意义的。相反，直接更新更有意义，可以避免不必要的数据库往返。
我的观点是，在我所看到的最常用的情况下，EF模型在大多数情况下不会暴露超过一层。这样可以确保View/UI层不会意外修改EF状态或导致延迟加载(通常会被禁用)。
然而，我仍然可以利用出色的EF/DB映射层和EF LINQ查询，这是EF迄今为止最大的功能。
像Dapper这样的大多数替代方案只是一个执行查询的框架。
因此，我不会因为您没有使用EF的所有功能而放弃使用ADO.NET或旧的查询技术您仍然应该使用现代查询框架，如EF或Dapper，因为您仍在执行查询仅仅因为你没有公开实体并不能改变这一点。