n層應用程序中的WCF服務層：性能考慮

當我去大學時，老師常說，在良好的結構化應用程序中，您有表示層，業務層和數據層。這是我聽了超過5年。n層應用程序中的WCF服務層：性能考慮

當我開始工作時，我發現這是事實，但有時更好的是不只有三層。兩三天前，我發現John Papa的this article解釋瞭如何在分層應用程序中使用實體框架。根據這篇文章，你應該有：

UI和表示層（模型 - 視圖模式）
服務層（WCF）
業務層
數據訪問層

服務對我來說，圖層是我工作以來聽過的最好的創意之一。然後，您的用戶界面完全從業務和數據層「連接」。現在，當我深入查看提供的源代碼時，我開始有一些問題。你能幫我回答他們嗎？

問題＃0：這是一個很好的enterpise應用程序模板在你看來？

問題＃1：我應該在哪裏託管服務層？它應該是Windows服務還是其他？

問題＃2：在提供的源代碼中，服務層只是暴露了一個WSHttpBinding端點。這是互操作性最強的綁定，但是（我認爲）在性能方面最差（由於對象的序列化和反序列化）。你同意嗎？

問題＃3：如果您在問題2中同意我的意見，您會使用哪種綁定？

期待您的來信。週末愉快！

馬爾科

來源

2010-04-10 Marconline

問題＃0：這是在你看來一個好的enterpise 應用程序模板？

是的，對於大部分中間道路行業應用，這可能是一個很好的起點。

問題1：我應該在哪裏託管服務層？它應該是Windows 服務還是其他？

如果您認真對待使用WCF服務，那麼是的，我會推薦自己託管它們在Windows服務中。爲什麼？您不必在服務器上安裝IIS，您不必依賴IIS來託管您的服務，您可以根據需要選擇服務地址，並且可以完全控制您的選項。

問題2：在提供的服務層的源代碼暴露只是與WsHttpBinding的端點。這是最具互操作性的結合，但是（我認爲）最差的表演（由於系列化和對象的 deserializations）條款。你同意嗎？

不，最具互操作性的是basicHttpBinding沒有安全性。任何SOAP堆棧都可以連接到該堆棧。或者對於RESTful服務使用webHttpBinding - 爲此，您甚至不需要SOAP - 只需HTTP堆棧即可。

我們用什麼？

內部，如果Intranet的場景是在遊戲中（服務器和企業防火牆後面的客戶端）：總是netTcp - 這是最好的，速度最快，功能最全的。難道不能通過互聯網很好的工作，雖然:-(（需要在防火牆上打開端口 - 總是件麻煩事）
外部：webHttpBinding或basicHttpBinding，主要是因爲它們易於集成與non-.NET平臺

來源

2010-04-10 12:36:49

好，所以在我需要打開我的業務層到內部應用程序的情況下，你建議netTcp，但如果這必須由外部應用程序訪問，你建議webHttpBinding或webHttpBinding。完善。非常感謝。 – Marconline 2010-04-10 18:11:57

是的，絕對使用netTcp的內部應用程序和訪問 - 你最好的選擇。從外部來看，通常是不可能的（因爲事實上你必須在防火牆上打洞，才能使流量通過 - 大部分幾乎不可能做到......） – 2010-04-10 20:19:13

這裏是我5毛錢：

0：是

1：我會在IIS託管，因爲它是很容易，讓你的地方快速啓動

2：如果您需要安全則肯定是有的，去與WsHttpBinding的（或者甚至wsFederationHttpBinding如果你想要更多FANCE安全）。它在實踐中表現得相當快，儘管如你所說，它確實有一些開銷，並且可能很難從其他平臺（如Java）調用。

3：N/A

最後，請記住在一個單獨的組件，其既可以從服務的dll 和消費者在UI層被引用來定義服務數據合同的對象。

來源

2010-04-10 12:43:09

好的，謝謝你的意見！ – Marconline 2010-04-10 18:10:27

難道你的老師也告訴你爲什麼你應該建立這樣的架構;-)？我在你的問題中缺少的是你的要求。在我們任何人都可以告訴你這是一個好的架構還是模板之前，我們必須知道應用程序的要求。應用程序的非功能需求或實際應該推動架構的設計。

我想知道什麼是您的應用程序的最重要的非功能性需求？（可維護性，可移植性，可靠性或...）。例如，看看http://en.wikipedia.org/wiki/ISO/IEC_9126或http://www.serc.nl/quint-book/

我認爲我們的架構師應該根據業務需求創建架構。這意味着我們的架構師應該讓業務更加了解非功能需求的重要性。

問題＃0：這是在你看來一個好的enterpise應用程序模板？

您使用圖層體系結構模式，這意味着圖層可以更容易地相互獨立演變。最常用的架構模式之一，請注意，這種模式也有缺點（性能，可追溯性）。

問題1：我應該在哪裏託管服務層？它應該是Windows服務還是其他？

難以回答。在IIS中託管服務有兩個優點，它更容易擴展，並且可追蹤性更容易（IIS中的WCF具有大量監視器選項）。在Windows服務中託管服務可爲您提供更多綁定選項（命名管道綁定/ TCP綁定）。

問題2：在源代碼中提供的服務層只是暴露了一個WSHttpBinding端點。這是互操作性最強的綁定，但是（我認爲）在性能方面最差（由於對象的序列化和反序列化）。你同意嗎？

表現明智WSHttpBinding的成本更高，但它在互操作性方面得分較高。所以選擇取決於你的非功能性需求。

問題3：如果您在問題2中同意我的意見，您會使用哪種綁定方式？

命名管道和TCP綁定非常快。名稱管道綁定只能在單臺計算機上通信時使用。 TCP綁定可能是一個選項，但您必須在防火牆中打開特殊端口。

來源

2010-05-06 20:29:20 Patrick

n層應用程序中的WCF服務層：性能考慮

回答

相關問題