我們正在構建可供其他系統使用的產品。因爲我們有SOA，所以我們只開發一個服務（WCF）。關於如何設計該服務的界面，我們曾經進行過多次有爭議的討論。我們正在選擇程序和麪向服務的OO設計。設計WCF服務接口。程序與面向對象的設計
由於我們的服務將從.NET和Java中使用，有人說如果它具有OO設計就很難與服務集成。其他人認爲服務不使用面向對象方法。有人說OO是完全正確的。結果我們沒有明顯的抑鬱症。
WCF提供了使用兩種設計的簡單方法，但最好的是什麼？
我假設您使用的「面向對象」的定義是管理「對象」的程序的概念，並且這些單獨的對象管理它們的內部狀態並公開要調用的函數。
對此最接近的WCF parralel是基於會話的服務，其中每個服務實例的生存期由客戶端控制。
如果您希望Java調用此服務，則必須使用basicHttpBinding，因爲它使用經典的Web服務協議。
此綁定不提供對基於會話的服務的支持，因此您實際上不能使用基於會話的服務。
因此，您無法將「面向對象」的範例應用於服務本身。
+1，而且採用OO方法進行服務設計會導致服務過於細化。你應該瞄準服務是粗粒度的。我想用'消息'而不是'對象'來思考。 – 2010-10-13 14:06:24
您通過說： 「澄清你的原始問題」如果他們接收復雜類型而不是標量參數，我的問題是關於服務的方法？
你應該問自己以下：
一）是否有該服務可以通過非面向對象的客戶端使用的任何機會呢？不知道，COBOL批次？即使貴公司已經在面向對象技術（Java/.NET）上進行了標準化，未來某種外部實體（客戶，PHP網站，不管）是否有可能使用此特定服務
b）您是否已經在過去創建了許多這樣的服務（所以你完全確定複雜類型沒有編組/序列化/反序列化問題，或者至少知道你可以安全使用什麼）？
如果您對這兩點都充滿信心，那麼可以在爲您的服務設計輸入和輸出時使用「OO」方法。否則，請選擇最安全（如果更原始）的方法，並分解標量組中的「對象」。
我看不出服務接口是如何真的，它只是一個Web服務接口。你問是否服務的方法應該返回/接收復雜類型而不是標量參數？如果這就是你要求的，使用複雜的類型。或者你問網絡服務的實現是否應該遵循面向對象的設計？ – JeremyWeir 2010-10-13 06:00:55
感謝您的回答。我的問題是關於服務的方法，如果他們接收復雜類型而不是標量參數？只是「使用複雜類型」不是一個爭論。 – 2010-10-13 07:05:03