我熟悉EF，它看起来很酷。据我所知，它基本上是一个带有额外功能的LINQ to SQL（如缓存，自动连接处理等）。但是，在我看来，EF对那些直接与模型数据（〜持久性）进行交流的应用程序非常有用。
在编写RESTful Web服务的情况下，我们正在以JSON格式读取和编写对象（例如）。应用程序使用一些数据调用Web服务，然后返回数据。
这就是为什么我实际上在想而不是使用EF，因为它看起来对我来说太过分了。由于我不打算公开实际模型，我会使用DTO（作为Web服务调用的输入和输出）。这意味着无论如何我必须映射到底层模型，因此EF将用作LINQ to SQL包装器。
有什么我想念的吗？在编写RESTful Web服务时是否有任何有用的功能？使用EF而不是LINQ to SQL有什么好处吗？
答案 0 :(得分：1)
所以这里的逻辑是你没有将你的实体暴露在数据层之外，所以EF毫无意义。
我从未公开我的EF实体通过业务层，只是从数据层向下一层。我总是把它们投射到只是POCO的ViewModels和Models。我在很多项目中都看到了这一点。
我实际上很少使用实体更改跟踪功能。当GET / POST发生时，重新查询POST上的实体是没有意义的，这样您就可以通过更改跟踪来更新它们。相反，直接更新更有意义，并避免了对数据库的不必要的往返。
我的观点是我最常见的，在大多数情况下，EF模型不会暴露在多个层之外。这可确保View / UI图层不会意外修改EF状态或导致延迟加载（通常是禁用）。
但是我仍然可以利用优秀的EF / DB映射层和EF LINQ查询，这是EF的最大特色。
Dapper等大多数替代品都是执行查询的框架。
因此，我不会因为您没有使用EF的所有功能而回退到只使用ADO.NET或旧的查询技术。 您仍然应该使用现代查询框架，例如EF或Dapper，因为您仍在执行查询。仅仅因为您没有公开实体而不会改变它。