ADO.NET Entity Framework跟蹤范圍是什么

本篇內(nèi)容介紹了“ADO.NET Entity Framework跟蹤范圍是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

社區(qū)對(duì)于ADO.NET Entity Framework和LINQ to SQL的***不滿，就是它不支持更改跟蹤。但只有在你連接到上下文對(duì)象的時(shí)候，你才可以修改對(duì)象并把它們保存回?cái)?shù)據(jù)庫(kù)。就像數(shù)據(jù)庫(kù)連接那樣應(yīng)該非?？?，一旦該上下文對(duì)象超出范圍，數(shù)據(jù)對(duì)象實(shí)質(zhì)上就進(jìn)入只讀狀態(tài)。重新附加它們到新上下文來(lái)回寫它們的更改，這并不是一個(gè)好辦法。

微軟拒絕解決該難題。他們沒有像大多數(shù)ORM庫(kù)那樣，在數(shù)據(jù)對(duì)象內(nèi)部添加更改跟蹤，改為更加關(guān)注POCO或者“簡(jiǎn)單初始C#對(duì)象”。

在Entity Framework設(shè)計(jì)博客上，微軟的三位開發(fā)人員概括了一些流行的數(shù)據(jù)庫(kù)訪問方法。***個(gè)是ADO.NET Entity Framework，它能夠回寫更改的集合到數(shù)據(jù)庫(kù)。他們列出了使用ADO.NET數(shù)據(jù)集的四個(gè)“問題”，但都意義不大。它們都集中在通過不可信邊界發(fā)送更改集合，也并沒有太大意義。數(shù)據(jù)集訪問和ORM庫(kù)用來(lái)凈化數(shù)據(jù)，而這本該應(yīng)用程序自己來(lái)處理。

下一個(gè)是DTO或數(shù)據(jù)傳輸對(duì)象。這僅是一種理想的說法，“我們先把所有數(shù)據(jù)放置在某些對(duì)象中，然后你來(lái)處理它?！边@與最近的討論并不相關(guān)，但確實(shí)說明了他們的想法。該話題接著簡(jiǎn)單地提到REST?，F(xiàn)在，我們知道ADO.NET Entity Framework團(tuán)隊(duì)已經(jīng)完全忘記自己應(yīng)該建立什么。至于他們所說的“目標(biāo)”，

隨著對(duì)Entity Framework進(jìn)行N層改進(jìn)，我們想解決一些相同的問題空間，例如數(shù)據(jù)集，但要避開它一些主要問題。 理論上，我們偏向于提供用于構(gòu)建的模塊，它正吸引開發(fā)人員在廣泛的架構(gòu)之上建立解決方案。例如，我們要給DTO支持者提供完善的控件，同時(shí)降低在解決簡(jiǎn)單方案時(shí)所承受的痛苦。

現(xiàn)在問題已相當(dāng)明了：ADO.NET Entity Framework不想成為另一個(gè)ORM，它想成為每個(gè)人所需的一切。ADO.NET Entity Framework就像我們一次又一次看到的那樣，這種方法不會(huì)讓人滿意?？匆幌略搱F(tuán)隊(duì)的聲明，除了這兩點(diǎn)，針對(duì)圖像中做變更的問題，還有一些更有趣的通用表示法，但一般來(lái)說，它們有著相同的缺點(diǎn)：給它們提供解決方案并不能授權(quán)給用戶控制的級(jí)別，這也是最復(fù)雜的解決方案和最成熟的模式所必須的。

“ADO.NET Entity Framework跟蹤范圍是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！