REST Web服務-實體框架是否過大？

Question

我熟悉EF，它看起來很酷。 據我所知，它基本上是具有額外功能（如緩存，自動連接處理等）的LINQ to SQL。 但是，我認為EF對於直接與模型數據（〜持久性）最小化的應用程序很有用。

如果編寫RESTful Web服務，我們將以JSON格式讀寫對象（例如）。 該應用程序使用一些數據調用Web服務，並返回數據。

這就是為什么我實際上在考慮不使用EF的原因，因為這對我來說似乎太過強大了。 由於我不打算公開實際模型，因此我將改用DTO（都作為Web服務調用的輸入和輸出）。 這意味着無論如何我都必須映射到基礎模型，以便將EF用作LINQ to SQL包裝器。

有什么我想念的嗎？ 編寫RESTful Web服務時，是否有任何有用的功能？ 使用EF而不是LINQ to SQL有什么好處？

Answer 1

因此，這里的邏輯是您不會將實體暴露在數據層之外，因此EF是毫無意義的。

我從未公開過我的EF實體通過業務層，而僅是數據層的下一層。 我總是將它們投影到只是POCO的ViewModels和Models上。 我已經在很多項目中看到了這一點。

實際上，我很少使用實體更改跟蹤功能。 到GET / POST發生時，重新查詢POST上的實體就沒有意義了，只是您可以通過更改跟蹤來更新它們。 相反，直接更新更有意義，並且可以避免不必要的數據庫往返。

我的觀點是，在我所看到的最常用的東西上，EF模型在大多數情況下不會暴露超過一層。 這樣可以確保View / UI層不會意外修改EF狀態或導致延遲加載（通常是禁用的）。

但是，我仍然可以利用出色的EF / DB映射層和EF LINQ查詢，這是迄今為止EF的最大功能。

諸如Dapper之類的大多數替代品就是這樣一個執行查詢的框架。

因此，我不會僅僅因為您沒有使用EF的所有功能而退回到僅僅使用ADO.NET或更舊的查詢技術。 您仍應使用現代查詢框架，例如EF或Dapper，僅因為您仍在執行查詢。 僅僅因為您不公開實體就不會改變這一點。