設計「Sometimes Off-line」的 Microsoft .NET 框架壓縮版應用程序

 

免责声明：本文为网络用户发布，其观点仅代表作者个人观点，与本站无关，本站仅提供信息存储服务。文中陈述内容未经本站证实，其真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。

 

簡介 越來越多的Microsoft? Windows? Powered Pocket PC開始連接起來，爲分布式應用程序帶來了新的可能性 即使很多Web應用程序對這些設備時可用的，還是經常會有對離線操作支持的需要。 在企業環境中爲了保持信息的一致性，離線應用程序需要與back-office 系統同步數據。 讓我們從一些結構基本原理開始。 在現代的應用程序設計中，多層式模式通常是作爲規則而非例外。 在服務器上我們越來越習慣于分離的用戶服務（通常是演示）、企業服務和數據服務。 通過使用像Microsoft Visual Studio .NET 2003這樣支持移動設備開發的工具，相同的模式可以被應用到移動應用程序 就「Sometimes Off-line」的應用程序而言，有一個應用程序運行在無服務器連接的工作設備上。 這一應用程序必須有多層式設計以獲得與服務器端應用程序相同的好處（基于組件的、可重用性、可維護性等等）。 圖1是對一個可能的分布式設計的高級別概述的闡釋。 [url=/bbs/detail_571224.html][img]http://images.wangchao.net.cn/images/upload/images/1166261274187.jpg[/img][/url] 圖 1：設備和服務器中的應用程序層 使用諸如Mobile Web Development with ASP.NET這類的技術，移動應用程序可以在服務器上完全實現。 然後，客戶端只使用內置的浏覽器來訪問應用程序。 如果需要支持離線功能，應用程序就要運行在設備本身上了。 與此相關的技術是 Smart Device Programmability和Microsoft .NET框架壓縮版。 返回頁首 同步策略 通常，分布式應用程序需要連接到一台服務器上以得到使命關鍵信息；而且因爲「始終連接」設備的夢想距離現實太遙遠，也經常有支持離線操作的需要。 因此，數據需要在設備本地維護，然後再與服務器同步。 對于與服務器同步離線設備數據來說，最令人感興趣的選項是數據庫同步和應用程序同步。 圖2闡釋了兩個選項概念上的概述。 [url=/bbs/detail_571224.html][img]http://images.wangchao.net.cn/images/upload/images/1166261274468.jpg[/img][/url] 圖2:數據庫與應用程序同步 數據庫同步是一種保持設備和服務器數據最新的非常有效的方法。 只有有必要的信息才被傳輸而且甚至以壓縮模式傳輸。 但是，如果在同步中涉及到邏輯，那麽需要有更程序化的方法來解決問題。 讓我們把這叫做「應用程序同步」，這意謂著在同步時設備上的業務邏輯層連接到服務器上的業務邏輯。 在許多真實的應用程序中，結合這兩種選項的設計會是最好的設計。 返回頁首 數據庫同步 如果設備上的數據是在SQL Server? for Windows CE （SQLCE）數據庫上維護的，那麽在.NET框架壓縮版中支持與SQL Server數據庫同步這些數據。 這種功能是在System.Data.SqlServerCe名稱空間的SqlCeReplication類中實現的。 可以采用的兩條路徑是遠程數據訪問（Remote Data Access, RDA）和合並複制。 RDA是推拉表數據出入設備的輕量方法。 另一方面，合並複制被用于更高級的同步。請閱讀文章 SQL Server 2000 Windows CE Edition and the .NET Compact Framework（英文）中的更多信息，有關合並複制的詳細信息，請參閱 Programming Merge Replication with the Microsoft .NET Compact Framework（英文）。 當數據同步中不涉及太多邏輯時，數據庫同步是很有趣的。 這是一個非常快的選項 — 尤其當是大量數據需要傳輸時。 它要求設備數據被存儲在SQLCE數據庫中。 如圖2中用虛線標明的，如果只涉及客戶端同步邏輯，使用System.Data.SqlClient名稱空間來訪問服務器數據庫也是可能的。 返回頁首 應用程序同步 在很多情況下，數據同步涉及到的邏輯需要有比數據庫同步許可更複雜的機制。 Application synchronization is much like application integrationtwo applications that connect to exchange data.應用程序同步很像應用程序集成 — 兩個應用程序連接起來以交換數據。 在.NET 框架壓縮版中，使其發生的最明顯的構造是通過XML Web服務的使用。 使用Web服務，設備可以以一種松耦合方法並基于諸如XML和HTTP等標准連接到服務器端邏輯。 在.NET框架壓縮版中對Web服務的支持可以在System.Web.Services名稱空間中找到。 如果需要更高級的同步方案，應用程序同步是應該選擇的。 讓我們看一個實現示例。 返回頁首 Reading Anyplace示例 Reading Anyplace示例應用程序展示了一個檢查員怎樣離線記錄計量器讀數然後將其與服務器同步。 這個應用程序由一個窗體組成，如圖3所示。 [url=/bbs/detail_571224.html][img]http://images.wangchao.net.cn/images/upload/images/1166261275031.jpg[/img][/url] 圖3：Reading Anyplace示例 可以輸入計量器ID和位置，當點擊Record按鈕時，記錄被添加到列表中。 每一個新記錄被標注爲「New」。 如果同一個計量器再次被使用，那麽相應的記錄就會更新。 當Synchronize按鈕被點擊時，每一個記錄都會通過Web服務送到服務器。 接著響應會在列表中的Remark列中更新。 一個正確的讀數被標注爲「OK」，同時不正確的讀數也會被標注，說明確認的錯誤（如圖3中ID爲1234的計量器被標注「太高！」）。 點擊Clean up按鈕清除列表中所有標注設爲「OK」的記錄。 這裏的邏輯是這樣的，直到設備數據與服務器同步之後，計量器讀數確認才能發生。 由于應用程序同步設計，這樣的反饋是可能的，而且如果用數據庫同步這將更難以實現。 返回頁首 代碼演練 因爲這個示例的中心不是要展示一個完整的服務器實現，服務器端Web服務實現看起來僅僅像這樣： [WebMethod] public string SyncReading(string ID, int Position) { if (ID == "1234" && Position > 1000) return "Too high!"; else return "OK"; } 示例Web服務是硬編碼的，只檢查ID爲1234的計量器在1000以上的計量位置。在實際方案中，可能應該用來自存儲在服務器數據庫中的以往讀數的位置預估來作一個比較。 同樣，如果來自其他檢查員的以往讀數被提供給客戶端，這個示例在服務器端將需要更多的同步邏輯。 在客戶端，當爲這個Web服務創建一個Web引用時，Synchronization按鈕的代碼看起來是這樣： Cursor.Current = Cursors.WaitCursor; Reading.Server.Sync sync = new Reading.Server.Sync(); try { foreach (ListViewItem lvi in lvwItems.Items) if (lvi.SubItems[2].Text == "New") lvi.SubItems[2].Text = sync.SyncReading(lvi.Text, Convert.ToInt32(lvi.SubItems[1].Text)); } catch (Exception ex) { MessageBox.Show("Could not call Web Service!", this.Text); } finally { Cursor.Current = Cursors.Default; } 當等待光標顯示時，Web服務對象（sync）被創建。 然後，在ListView中的每一個新記錄（標注爲「New」）被送到Web服務方法（SyncReading），ListView中的Remarks列由Web服務響應更新。 如果有什麽錯誤，會顯示一個消息框，無論發生了什麽，光標都被還原。 在本示例中，本地數據只在ListView控件中維護，當示例應用程序結束時，數據就丟失了。 在實際方案中，這些數據可能被傳輸到一個DataSet並作爲一個XML文件或在一個SQLCE數據庫中存儲。 返回頁首 小結 當有諸如服務器端確認之類的邏輯的需要時，應用程序同步是在「sometimes off-line」應用程序中實現同步的優先選擇。 Web服務是實現應用程序同步的平滑方法，因爲這樣能允許客戶端邏輯連接到服務器端邏輯。 因此，對于從一個基于.NET框架壓縮版的Pocket PC應用程序調用Web服務來說，本機支持是真正有價值的。