每當我看到有關實體框架的演示時，演示者只需設置一些表並使用自動創建的代碼存根執行插入，更新和刪除操作，但從不顯示任何存儲過程的使用。在我看來，這是從客戶端執行SQL。如何在典型的業務層/數據訪問層/存儲過程設置中使用EF？
根據我的經驗，這不是特別好的做法，所以我假定我對實體框架的理解是錯誤的。
同樣WCF RIA服務演示使用EF和演示始終相同。任何人都可以闡明如何在典型的業務層/數據訪問層/存儲過程設置中使用EF。
我覺得我很困惑，不應該!! !!？
從客戶端執行SQL沒有任何問題。當使用類似EF的東西時，大多數（如果不是全部的話）可能導致的問題實際上並不存在。例如：
從來沒有顯示有任何使用存儲過程
看看這個視頻：Using Your Own Stored Procedures to Insert, Update and Delete Entities in Entity Framework。
請注意，那裏有很多其他視頻，值得一看！
回到舊的客戶機/服務器時代，過去認爲使用存儲過程進行所有數據庫更新是一種很好的做法。
但是現在，擁有O/RM生成SQL並直接針對數據庫運行是完全可以接受的。
那麼，爲什麼在存儲過程中執行sql是一個好主意的一部分原因是它提供了一個抽象級別 - 當數據庫變化不可避免地發生時，您在一個地方（proc）進行更改，而不是十幾個地方（所有你調用客戶端sql的地方）。實體框架通過數據模型提供了這個抽象層，並且您具有相同的優勢。
還有一些其他的原因，你可能想看看procs，如安全粒度（只允許某些用戶執行權），以及一些小的性能差異。最終，你必須自己決定什麼是正確的折衷。 EF試圖大幅降低開發人員在創建數據層時所需的時間，並在上面進行權衡。
的傳說是，Scott Hanselman曾經說過「除非有人拖動一個DataGrid這是不是一個真正的演示」（第478的Silverlight 4在行動上，皮特·布朗）
你一定要記住，演示，都是關於銷售軟件，而不是溝通最佳做法。因此，您對演示的觀察是絕對正確的，它們涵蓋了基本知識，並將其留給觀察者來填補空白。
關於您對存儲過程的評論以及有關您的關於生成器的問題的各種答案。發電機是好的，並越來越好。 Howerver在某些情況下會產生完全不可用的查詢。 （見我的SO質疑here和discussed on the ADO.NET team blog）
因此有些時候手工製作的查詢是你唯一的辦法（通過存儲過程，表值函數，意見等方式）
感謝您的詳細解答。我的直覺告訴我，如果不考慮你提到的事情，EF就不可能發展起來。我特別關心安全。現在我覺得可以更多地接受它，並付出時間和精力去真正「得到它」。 – EzaBlade 2010-12-06 21:13:24