自我跟蹤實體與POCO實體

我們正在開始一個新的基於網絡的產品，我們計劃通過WCF服務公開我們的業務邏輯。我們將使用ASP.NET 4.0，C＃，EF 4.0。未來我們希望基於這些服務構建iphone應用程序和WPF應用程序。我一直在閱讀很多有關使用POCO vs自我跟蹤實體（STE）的信息，並且從我的理解中可以看出，STE在Web方案中效果不佳。任何人都可以在這個問題上找到更多的信息自我跟蹤實體與POCO實體

來源

2010-09-28 Kumar

我明白這個問題是前一陣子問過的，但我很好奇你最終決定了什麼POCO vs STE的情況？ – 2012-07-13 13:35:44

對我來說STE是絕對錯誤的概念。這只是DataSet的另一個實現。

在ASP.NET應用程序中，您將不得不在請求之間存儲STE。在第一個請求中，您將查詢您的數據源以獲取STE並在頁面中提供數據。在下一個請求（回發）中，您將需要使用瀏覽器返回的數據修改STE。爲了支持跟蹤，您必須使用與第一個請求中相同的STE = >，您將必須在視圖狀態（如果要使用ASP.NET WebForms）或會話中存儲STE。
STE對SOA或互操作性無用。跟蹤邏輯是STE =它在客戶端上運行的一部分。如果您在服務中暴露STE，您將立即希望客戶端使用STE邏輯中包含的相同跟蹤功能。但是這些功能不會自動提供給其他方。在.NET中，您擁有它們是因爲您與STE共享程序集。但是在其他平臺上，您必須向開發人員解釋如何實施STE邏輯以使其在您的一邊工作。由於iPhone應用程序，這可能是您最受限制的情況。

來源

2010-09-28 18:39:28

在ASP.NET中，爲什麼不直接在第一次請求時顯示STE並在回發時從數據庫中獲取STE，更新字段並保存？ – 2010-09-28 18:44:14

如果您對額外的數據庫查詢感到滿意，除修改複雜的對象圖外，根本不需要STE。你可以讓ObjectContext（帶有POCO代理）來跟蹤你的變化。 – 2010-09-28 18:49:39

「STE對於SOA或互操作性無用。」我完全同意。不幸的是，人們似乎堅持將SOA和WCF視爲遠程處理。當然，它可以完成，但是你對客戶非常信任。 – 2010-09-28 19:09:27

自跟蹤實體在WCF場景下可以在MVC Web中完美工作。我參與了兩個使用它們的項目（一個在生產中，一個在生產中）。

使用POCO，您將失去通過電線進行的任何更改跟蹤，這會造成很多額外的痛苦，因爲EF現在必須重新查詢狀態信息。如果你使用EF和WCF STE解決了很多問題，並且讓你的整個持久化管道非常流暢。

您能否提供此聲明的引用？「STE在網絡場景下效果不佳」

來源

2010-09-28 18:10:52 jfar

你如何在請求之間保持你的STE（例如GET - > POST）？ – 2011-01-19 12:42:46

@jfar，在WCF場景中，如果您使用STEs（又名自我跟蹤實體），則「平臺獨立服務」的概念將丟失。例如，如果有一個Java客戶端應用程序想要與WCF服務進行交互會發生什麼。 Java客戶端應用程序如何在客戶端獲取SET？不幸的是，它根本不能！意思是，如果我們使用STE，那麼我們的WCF服務只能由建立在.Net中的客戶端使用。可怕的是不是？ – Baig 2011-08-02 12:01:13

如果這個服務將被任何你沒有直接控制的應用程序佔用，你應該強烈考慮與EF（或nHibernate或Linq2Sql或任何其他數據持久化管理解決方案）來自您的服務和您的數據傳輸對象。這將隔離破壞客戶的內部變化。打破客戶通常是一件壞事。

來源

2010-09-28 21:07:15

請參考http://msdn.microsoft.com/en-us/data/jj613924.aspx，因爲STE不再推薦！ Microsoft建議使用任何ASP.NET Web API，WCF數據服務或實體框架API（複雜操作）

來源

2012-10-30 09:44:52

自我跟蹤實體與POCO實體

回答

相關問題