新聞中心
學(xué)習(xí)ADO.NET解決方案的問題,提供完整的解決方案,他們將不會給開發(fā)者帶來任何東西。開發(fā)人員不得不在Entity Framework之上建立自己的ORM,如果他們確實要在上下文外部操作數(shù)據(jù)的話。

創(chuàng)新互聯(lián)建站專業(yè)提供成都主機托管四川主機托管成都服務(wù)器托管四川服務(wù)器托管,支持按月付款!我們的承諾:貴族品質(zhì)、平民價格,機房位于中國電信/網(wǎng)通/移動機房,服務(wù)器主機托管服務(wù)有保障!
本文的余下部分是相當(dāng)冗長的示例,它關(guān)于如何使用新API來執(zhí)行更改跟蹤。這包括創(chuàng)建接口(例如IEntityWithChanges)、像 GetEntityState那樣使用手寫的方法進(jìn)行映射、或者在一個方法中兩者都使用,該方法接收上下文對象、實體狀態(tài)名稱、實體圖的方法與實體狀態(tài)映 射等。記住,這只適用于保存更改,你仍要先以某種方式跟蹤該更改。
ADO.NET解決方案了它是如何完成的:
下面是用NHibernate的處理方法:
session.Merge( entityFromPresentationLayer );
Frans' LLBLGen支持類似的功能。換句話說,這是數(shù)據(jù)訪問框架做的事,而非開發(fā)人員。
談到Frans Bouma,下面是他總結(jié)的一些情況,#t#
所有那些使用數(shù)據(jù)集的開發(fā)者,如何確信EF是正確方式呢?數(shù)據(jù)集在什么時候解決過這個問題的呢,從一開始嗎?更別提是不是那些大 量競爭性的O/R映射器框架?我想核心的問題是設(shè)計框架的錯誤,從框架開發(fā)人員的角度來看:ADO.NET解決方案在你編寫框架時,有兩種“正確點”——來自框架開發(fā)者的觀點 (Point Of View,POV)和來自框架用戶的觀點。核心的錯誤是假設(shè)這兩種“正確點”實際上是一樣的,更糟糕的是:假設(shè)框架開發(fā)者關(guān)于“正確點”的觀念,即是框架 用戶所想。
在之前的例子中,所有放在對象創(chuàng)建中的查詢結(jié)果都被添加到ADO.NET解決方案r中,因此我們能夠跟蹤它們的更新。如果沒有必要跟蹤對象的更新和刪除,那么最好是使用NoTracking合并項。例如,在一個ASP.NET Web應(yīng)用程序中,如果它要查詢一個指定的分類名稱,但卻不需要對返回的數(shù)據(jù)進(jìn)行更新,那么NoTracking就會是一個不錯的選擇。在這種情形下,使用NoTracking的查詢會在性能方面得到改善。
新聞標(biāo)題:如何解釋ADO.NET解決方案說明
網(wǎng)站鏈接:http://www.fisionsoft.com.cn/article/cdoseps.html


咨詢
建站咨詢
