我想知道在WCF服務中是否推薦使用Self Tacking Entities(在實體框架中)?如果是的話,那麼你能指導我一個教程,可以指導如何做到這一點?建議使用自追蹤實體和WCF服務嗎?
其實,我打算開發一個使用Prism和MEF和MVVM的WPF應用程序。我決定使用實體框架。我需要關於這種方法的建議和建議。
任何幫助將不勝感激。
我想知道在WCF服務中是否推薦使用Self Tacking Entities(在實體框架中)?如果是的話,那麼你能指導我一個教程,可以指導如何做到這一點?建議使用自追蹤實體和WCF服務嗎?
其實,我打算開發一個使用Prism和MEF和MVVM的WPF應用程序。我決定使用實體框架。我需要關於這種方法的建議和建議。
任何幫助將不勝感激。
我想知道,如果使用自套結實體(實體框架)建議使用WCF服務 ?
這取決於你問誰。如果你問MS他們會告訴你是因爲他們根本沒有更好的報價。國有企業對這個很老的MS Connect suggestion作出了迴應。問題是,EF本身具有terrible bad support兩個實體圖之間的合併更改(你必須這樣做完全自己)和開發人員對MS平臺上工作(有時也包括我)有一些共同的行爲:
前兩點是MS策略的結果,其中RAD成爲設計師(或新近也是T4模板)的同義詞。
我share @理查德對STE的看法。我會增加一個STE的另一個缺點 - 他們在參與者之間移動大數據集。如果您決定從服務器獲取實體圖,則更改圖中的單個實體並將數據推回,它們將再次傳輸整個圖。只傳輸更改的實體會導致與STE的核心邏輯發生衝突。我也擔心他們會在每個實體級別而不是按物業級別完全跟蹤更改。如果修改具有較大二進制或字符串數據的實體,可能會導致在服務和數據庫之間以及服務和客戶端之間傳輸太多不需要的數據。
無論如何,對於低數據流量和小實體的簡單應用程序,他們可以很好地完成工作,並允許您快速構建應用程序,但無需嚴格區分問題。您將從服務中獲取實體並將其直接綁定到WPF UI,並且他們將能夠跟蹤您的更改。稍後,您會將實體推回服務,並且他們將能夠堅持更改。您的客戶和服務將緊密結合,但在某些情況下,它可能足夠好。