2009-05-02 42 views
2

如何創建可作爲XBAP部署的WPF應用程序或作爲本地Windows應用程序以儘可能少的開銷部署? XBAP與WPF Windows應用程序二進制兼容,並且在相同的CLR之上運行(與Silverlight不同)。它們在某些方面仍然不同。雙重部署WPF應用程序本身並作爲XBAP

從部署的角度來看,它們最大的區別在於,當Windows應用程序具有Window控件時,XBAP具有Page控件作爲主容器。讓Windows應用程序使用Page控件是相當簡單的,但我感覺(可以自由地不同意)在Windows應用程序中使用頁面導航方法相當不直觀。

第二個主要區別是默認情況下,XBAP在部分信任的環境中執行。這可以被繞過,並且XBAP可以在完全信任模式下運行。使用XBAP的部分信任模式意味着您無法直接訪問例如遠程Web服務或來自XBAP的本機代碼。

什麼是一個容易和可維護的方式來實現以上問題與以下問題?

要求

  1. 部署在兩個方面:作爲一個XBAP通過HTTP和作爲一個獨立的WPF可執行文件。
  2. 顯示來自遠程Web服務器(如flickr)或非託管API的信息。
  3. 如果可能,部署方法應該忠實於他們的平臺。也就是說:在XBAP中使用頁面,這些頁面在Windows應用程序中是有意義的,對話框是有意義的。

限制

  1. 平臺優化。 XBAP所需的東西不應該影響Windows客戶端,反之亦然。
  2. 部署選項共享盡可能多的代碼。這有助於測試和維護。
  3. 運行XBAP應該儘可能簡單。證書先決條件將會破壞XBAP的目的。

我收集的是第一個需求需要兩個單獨的項目。第二個限制可以通過具有包含所有UI並且由兩個部署項目引用的用戶控制項目來處理。 WCF Web服務可以解決XBAP的侷限性。

如果採用類似於上述各行的解決方案的第一限制將需要一些工作作爲Windows客戶端可以在不WCF服務做的,因爲它是已經完全信任模式下運行。第三個需求也需要一些特定的部署代碼,這樣所有的UI代碼都不能在用戶控制項目中。

我想知道有什麼解決辦法可以用來解決這些問題。隨意忽略部分解決方案。它主要是爲了解釋這一點,並防止「已經有過這種想法」的評論。因此,爲了澄清,我對全部解決方案感興趣,而不僅僅是那些遵守部分解決方案的解決方案。

對此感興趣的原因是,解決方案意味着無需在WPF Windows應用程序和XBAP之間進行思考,因爲這些應用程序都可以在創建時多付出一點努力,並且客戶端可以選擇最適合他們的任何一種。

回答

2

您可能想看看Prism(at codeplex) 它有助於以最少的代碼更改(額外工作量取決於您的項目)來定位Wpf,Xbap和Silverlight。

下面是如何使用它來創建WPF和XBAP應用:Prism and XBap Applications

+0

嗡嗡聲。通過快速瀏覽,Prism似乎專注於源代碼級代碼共享。這在WPF和Silverlight之間是必需的,因爲這兩者不是二進制兼容的。我主要是指彙編級代碼共享。雖然這是一個快速瀏覽。早晨需要更好看。 – 2009-05-02 23:07:16

0

我試圖多年來幾種方法來此。最適合我的是在一個解決方案中有四個項目:

  • 構建包含業務對象,通信和UI的dll的主項目。
  • 含手動和自動的單元測試
  • 爲Windows應用
  • 一個微小名.xbap項目

在主項目既沒有頁也不視窗一個微小.exe項目的測試項目,只是UserControls和自定義控件。還有一個用於顯示UI的服務類。這個類在Windows和XBAP項目中被分類以改變事物的顯示方式。在每種情況下,子類都在應用程序啓動時安裝在靜態屬性中。所有其他的代碼只是引用這個靜態屬性並調用它的方法。這些方法執行Windows和XBAP應用程序之間不同的服務。

例如,我的服務類有一個「ShowDialog」方法,該方法接受FrameworkElement並以對話框樣式(Window應用程序)或頁面上的Popup(用於XBAP)顯示它。

使用此技術可以在Windows應用程序和XBAP之間共享大約98%的代碼。

我的主應用程序還定義了客戶端 - 服務器接口,並將WCF屬性應用於其數據對象。所有代碼都有一個靜態屬性用於訪問服務。這個靜態屬性被初始化(在類的構造函數中)爲具體實現類的一個實例,但XBAP項目中的啓動代碼將其替換爲WCF客戶端,所以XBAP運行客戶端服務器,並且Windows應用程序實際上將本地調用。在每種情況下,它都是服務器端的完全相同的對象。

因爲我實現了WCF作爲接口,所以我只能爲WCF服務結束事情而僅僅使用一個簡單的.svc文件,並且不需要單獨生成代碼或在代理/存根代碼中進行鏈接。