我們正在開發一個mvc網絡應用程序，用戶界面將會很快響應，所以看不到任何將要使用服務的本地應用程序所需的Web服務的未來需求。但是，如果我們想在客戶端使用Angular js，那麼是的，這是必需的。如果不需要，Web服務是否會創建開銷？
現在的問題是：
請問性能的情況下，我們越使用項目庫（服務庫不是web API），而不是使用的Web API創建REST服務？或者如果我們使用休息服務不會有太大的區別？
我相信包括服務項目庫的參考將是最好的選擇，如果不需要休息服務。當來自客戶端的請求轉到服務器時，它不需要另外的http請求來調用其他服務。
這兩個世界的最好的將包括服務項目庫的參考，但設計它們的方式，你可以有一個非常薄的層 - 一個ApiController - 只處理WebService安全性，如果有的話，邏輯。
如果你做得對，控制器應該除了調用你的服務類之外幾乎沒有代碼。
其他優點：您可以實現一些控制器，將您的服務作爲REST服務公開，只是爲了證明您獲得了它的要點並確保您的架構能夠正常工作，然後在以後的日子裏公開所有其他服務作爲您需要的RESTful API，當您切換到AngularJS時。
如果您針對服務類構建代碼，這可能會很麻煩。可能會出現序列化問題（循環引用，不可序列化的類），直到您嘗試從Web服務提供它們時纔會注意到這些問題。 – CodeCaster
我不確定在這種情況下循環引用是如何發生的，但是你有一個關於這樣一個事實的觀點：明智地選擇在這些服務返回的對象中公開的類型，否則，需要更多的代碼來確保它們可以序列化。 –
圓形引用很容易創建，例如通過返回'Order'和'List
Web服務的開銷與調用次數成正比。通過撥打100000次無操作服務來衡量它。您可能每個CPU內核每秒鐘可以獲得1000-5000次呼叫。
此度量不包括網絡延遲。
取決於您的應用程序的多麼有趣，perf的成本可能接近零或破壞性。
添加Web服務層時，最大的擔心通常是生產力成本。這很重要。您不能再在圖層之間共享對象並依賴對象標識。一切都被複制。例如，客戶端沒有使用ORM。
Web服務不是你輕易添加的東西。也許你可以將你的代碼構建爲一個稍後可以放入Web服務的庫。但是，這很難得益於國家不能共享的根本問題。
許多優秀的問題都會根據專家的經驗產生一定程度的意見，但對這個問題的回答往往基於意見而非事實，參考或具體專業知識。 – Epodax
正確，你有沒有遇到這種情況？或者您是否有正確答案的任何事實/參考？ –
你在這裏有什麼問題？您正在構建將直接使用dll的原生應用程序，並且您想知道您是否仍需要apis？ –