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