ASP.NET MVC n層架構

Question

我有一個標準的nteir設置： -

Web服務器 - >應用服務器 - >數據庫服務器

我有一個MVC 5 Web應用程序坐在控制器調用Web服務器上一個坐在App服務器上的WCF服務項目。 WCF服務項目使用EF6來封送數據庫服務器上的數據。

我想知道如果WCF是矯枉過正？是否有更簡單的方法來實現這個相同的架構？我想我應該在應用程序服務器上使用Web API，然後使用HTTPClient從控制器調用Web API？

或者，我甚至可以在App服務器上使用普通的MVC項目，將JSONResults返回給Web服務器上的MVC控制器？

Answer 1

這取決於...

你必須明白每個設置的好處。這並非詳盡無遺，只是一個快速轉變。這應該給你一些提示，以便在野外世界看得更遠，可能有更多的理由選擇一個或另一個解決方案。

• 爲什麼選擇WCF。你將有不同的客戶到你的後端？您需要在客戶端和後端之間提供一些entreprisy安全性？藉助WCF，您可以配置Http，TCP端點，設置消息或傳輸安全性等等。例如，如果你在做一個Intranet應用程序，並且你不僅希望擁有你的UI（MVC應用程序），而且還有其他系統需要它，那麼可能需要它。如果這不需要，WCF似乎在這裏矯枉過正。
• 如果您希望構建更多面向REST的api，爲不同客戶端（不同媒體類型）啓用內容協商，則Web Api也是非常不錯的選擇。構建REST不是關於發佈JSON，更重要的是，這裏解釋它太長了。如果你的客戶不僅僅是你的MVC應用程序，而且你可能需要一個用於其他移動設備的api，OAuth認證等等，這可能是一個很好的方法。
• 平原MVC應用程序也適合，如果你沒有任何特殊需求，去爲它。沒有需要的開銷。 保持簡單和愚蠢。

我希望這有助於

Answer 2

我不會改變這一點。

WCF是Web Tier和App Tier之間溝通的好選擇。我永遠不會把我的App Tier暴露給外部世界，所以如果有任何來自外部世界的應用程序通信，它將僅通過Web層，並且如果需要支持多個客戶端，我會在Web上創建一個WebAPI並揭露這一點。

我會保持應用層僅適用於組織內部和WCF我可以靈活地編寫服務代碼和合同，然後可以通過各種綁定（傳輸，安全等）暴露如果您正在構建服務在您的組織中，並計劃支持多種協議，或者僅使用HTTP以外的協議（tcp，名稱管道，udp等），那麼WCF確實是一個不錯的選擇。