何時不使用實體框架

.net architecture c# entity-framework

我一直在玩EF,看看它能處理什麼。此外,許多文章和帖子解釋了可以使用EF的各種場景,但是如果以某種方式錯過“con”方面。現在我的問題是, 在什麼樣的情況下我應該遠離實體框架

如果你在這個領域有一些經驗,請告訴我哪些場景不適合EF。告訴我你經歷過的一些缺點,你會選擇不同的技術。

一般承認的答案

我也只是在'玩弄'階段,雖然我擔心缺乏內置的持久性不可知論,但我確信會有“解決方法”。

事實上,甚至在n層架構中都沒有解決方案。

WCF + EF

如果我正確地閱讀了這篇文章 ,那麼我沒有看到任何問題通過網絡序列化實體(使用WCF),並且持久性無知也不是問題。

這是因為我主要使用PI進行單元測試。

單元測試可能的! (我認為)

在這個系統中,我們可以簡單地使用模擬服務(通過在基於另一個接口的類中包含對服務的調用,例如可以從工廠生成)。這將測試我們的演示者代碼(不需要對EF / DAL進行單元測試 - 這是微軟的工作!)當然,仍然需要進行集成測試才能充分發揮自信。

如果你想寫一個單獨的數據庫,這將在DAL層完成,可以通過配置文件輕鬆實現。

我的Tuppence值得

我的觀點 - 對EF進行自己的思考,並且不要因為那些正在進行巡迴賽的所有厄運和沮喪而被推遲。我猜它會在一段時間內出現,MS會在明年左右解決這些問題。根據Dan Simmons的說法,PI肯定會出現。

編輯 :我剛剛意識到我跳了槍,就像一位優秀的政治家實際上沒有回答被問到的問題。哎呀。但我會留下這個以防萬一其他人發現它有用。


熱門答案

無信任投票列出了那些認為他們知道什麼功能及其實現適合ORM / Datamapper框架的人眼中的幾個失誤和/或缺失的功能。

如果這些問題都不是什麼大問題,那麼我不明白為什麼你不應該使用它。我還沒有聽說這是一個左右爆炸的車子。所有反對它的警告都是哲學的。我碰巧同意不信任投票,但這並不意味著你應該這樣做。如果您碰巧喜歡EF的工作方式,那就去吧。與此同時,我建議你至少閱讀不信任投票,並嘗試對每個問題進行初步了解,以便做出明智的決定。

除了這個問題和問題的核心 - 您需要密切關注正在生成的Sql,以便在性能問題投入生產之前進行調整。即使你在後端使用過程,我仍然會尋找你可能會多次訪問數據庫的情況,然後重新編寫映射或相應地獲取方案。



許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因
許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因