2011-02-04 60 views
3

我正在研究將基於最新的.NET和SQL Server技術的大型企業應用程序的體系結構。此應用程序將由普通公衆,成員,員工和管理人員使用。使用Windows和Web界面編寫企業應用程序的最佳方法?

過去,我們使用RemoteApp/RemoteDesktop與服務器上運行的本地Windows Forms應用程序對話。簡單但笨重。

  • 應用程序的某些方面需要呈現爲Web應用程序。
  • 應用程序的某些方面需要作爲Windows窗體應用程序呈現。

Windows應用程序需要分發給不同地區的受衆(分支經理和員工)。

下面是Windows界面的目標:

  1. 「瘦客戶機」,它的行爲類似於Web瀏覽器(用戶只接口)
  2. 所有的處理要對完成服務器
  3. 利用該web應用做了同樣的代碼庫 - 只是不同的UI
  4. 直白的開發(易於維護和發展)

什麼是一些最好的方法呢?

(我已經花了很多時間相當看着.NET遠程,然後WCF,但我沒有經驗的clairty,我希望你能帶)。

謝謝!

回答

2

我有一個工作中的應用程序,它具有Web界面和WCF服務界面。另一個應用程序(一個WinForms應用程序)使用WCF服務來提供Web應用程序提供的相同功能,但僅限於WinForms應用程序正在執行的內容。關於它的好處是,實際功能位於業務層,而Web應用程序和WCF服務都只是呈現不同的UI訪問方法。

從你所描述的,類似的東西會工作。真正的關鍵是確保儘可能少的業務邏輯嵌入到ASPX頁面中。也就是說,你將不得不重新創建它的WCF端。

所以你想創建一組業務邏輯類,可以執行應用程序的實際功能。然後您的網頁包含表示邏輯。如果你這樣設置它,那麼創建一個WCF服務就可以很直接地向調用程序公開相同的業務邏輯。這部分是整個事情的真正關鍵。您只需要將邏輯放在一個位置,以便更改它可以同時更改這兩種類型的呼叫者。

如果您使用的是Web服務WCF綁定之一,您可以將服務文件粘貼到Web應用程序中並將它們放在一起。如果您使用的是活動目錄身份驗證等功能,那麼您可以同時利用這兩種訪問類型(因爲這是一個內部WCF服務,而不是面向Internet的公共服務器,因此可以正常工作)。

我首先從它的Web應用程序端開始,一旦它做到了你想要的,你可以在之後添加WCF服務來保持項目的可管理性。

至於WCF vs遠程處理,在這種情況下,我傾向於WCF。它與網絡應用程序非常匹配。

編輯:

1)接口 - 你需要在.svc文件一個類來實現服務調用不管是什麼。對於某些類型的服務(basicHTTPBinding,這是基於SOAP)的服務協定需要一個接口,但對於其他類型(基於REST的webHTTPBinding)則不需要。不管怎樣,我可能會編寫一個接口,它可以讓您在不更改服務合同的情況下更改服務實現,這是客戶需要保持一致的。

2)當然可以從網絡應用程序調用服務,但它會爲網絡應用程序添加額外的工作層。對於HTTP服務,這也意味着您的服務將XML序列化爲一切,然後您的Web應用程序將需要立即反序列化它。 XML序列化帶來顯着的性能影響。我會避免使用這種方法,因爲Web應用程序可以更有效地綁定業務層返回的業務對象(並且WCF將XML自動將其序列化爲服務的客戶端)。如果您的網絡應用程序需要在另一個應用程序中調用另一個服務,那麼這將是一回事,但在這種情況下,它不是要走的路。

3)如果是面向公衆的,你如何驗證它的變化。對於內部的東西,您可以讓IIS使用Active Directory處理身份驗證。如果你有Internet客戶端,他們可能不在Active Directory中,你需要使用其他方法。 (HTTP基本和摘要認證應該仍然沒問題,或者你可以做一些事情,比如把用戶名/密碼作爲參數添加到需要認證的方法中。一定要在服務上使用SSL!)

+0

嗨,感謝你的好消息。我有幾個問題,如果您願意更新: 1.您會使用接口或類來定義WCF服務嗎? 2.從Web應用程序(同一個項目)直接調用WCF服務實現是否可行/可行?因此,您以後確實只有一個「門戶」通往您的業務? 3.你提到「這是一個內部的WCF服務」......不,它會是公共的(通過驗證的) - 這是否改變了什麼? 謝謝! – gahooa 2011-02-05 04:14:58

相關問題