0
當涉及到WCF服務中的組織/構造方法時,什麼被認爲是最佳實踐?如何在WCF服務中將方法組織/結構化爲名稱空間?
讓我們假設我有一個.net dll,我想通過WCF服務公開。
在.NET的DLL有一個命名空間結構是這樣的:
Root
-- > SubNameSpace1
-- > SubNameSpace2
-- > -- > CategoryA
-- > -- > CategoryB
-- > SubNameSpace3
我怎麼會通過WCF服務公開此命名空間結構? (因爲我不希望所有名稱空間中的所有方法都合併爲調用該服務的客戶端對象的方法。)
何時適用/建議創建不同的* .svc文件? (關於我的命名空間結構)
讓我們假設我已經有一個工作的DLL直接調用數據庫。我不想再有這種行爲了。相反,我想通過WCF服務「路由」所有呼叫。我正在考慮如何擁有相同的命名空間。我想通過「設計一種服務,以面向服務的方式公開一系列連貫的功能」,你的意思是,我希望命名空間不可能? – citronas
我的意思是你「暴露」你的DLL犯了一個錯誤。不要「暴露DLL」。寫一個服務。 _使用DLL來實現該服務。您可能會發現,您設計用於執行與DLL相同功能的服務將具有與DLL相比非常不同的界面。 –
好吧,我同意這一點,如果參數不同(例如服務調用需要額外的參數,實現服務的DLL不需要公開),則封裝服務調用的DLL將會很有用。但主要問題仍然是:如何組織服務中的方法。我不希望像GetComments(...),GetFoo(),GetBar(),InsertComment(..),DeleteComment(...)等所有方法成爲客戶端wcf對象的方法。我寧願有一個MyWCFClientObject.Comments。 ...或MyWCFClientObject.Foo。 ...名字空間。 – citronas