我有我建立一個移動應用的解決方案 - 到目前爲止，這包括兩個項目：分裂的WebAPI項目和前端工程解決方案
1) WebAPI for API/DAL/SQL etc
2) Web for single-page front-end
Web項目，使該項目的WebAPI調用。計劃是爲Windows 8應用程序創建另一個項目，爲WP8應用程序創建另一個項目等。
這在開發過程中運行良好，但CORS，部署等已變得非常複雜（Web由與WebAPI不同的端點 - 兩個Azure網站）。我的問題是 - 在構建由REST-ish API支持的解決方案時，將解決方案分成多個項目是明智的還是不明智的？
我總是分裂API和前端成單獨的項目的幾個原因：
前端依賴（jquery的，敲除，角....）使API比必要重。篩選「其他」項目類型的代碼可能會減慢開發速度。
在一個項目中跨兩個功能單獨的項目提交時，源代碼管理可能會有點混亂。如果您在一次提交中更改API和網站，但希望將其中一個恢復到較早的時間點（或分別推廣它們），這將成爲頭痛的問題。
通過將項目放在一起，您必須一次更新共享依賴項（升級到新版本的.NET？）。如果您的API代碼依賴於折舊代碼，則升級可能會很困難，您的網站升級可能會被阻止（反之亦然）。
如果它們在同一個項目中，則不能輕鬆發佈API或前端。正常情況下， API將在您完成與網站的視覺方面的混合之前完成並保持穩定。每當您進行次要站點更改時，您都不希望被重新發布API所阻止。
將兩者都作爲同一個項目需要您在同一個Web服務器上運行（並在同一個應用程序池中！）。如果你打算讓多個源代碼訪問你的API（通常是API的一部分），那麼你不希望API由於對網站的請求而降級。這是雙向的，如果你的API遭到重創，你不希望你的網站變得沒有反應。
由於它們將運行在同一個應用程序池中，它們也將以同一用戶身份運行。出於安全考慮，您可能希望API應用程序池作爲一個單獨的服務帳戶運行，該帳戶具有對數據源的集成身份驗證訪問權限。然後，您可以鎖定網站用戶帳戶，並禁止其訪問外部資源。
由於MVC webapi模板爲前端提供了所有的依賴關係和配置，將它們放在一起可能看起來合乎邏輯，但僅僅因爲它們使它變得容易並不意味着它應該以這種方式完成。我通常會剝離此模板中提供的前端，並將其製作成簡單的頁面來描述如何使用API。最終，MVC本身就是關注問題和清潔開發的分離。我會說，分離項目類型遵循這個邏輯。
我想不出將Visual Studio解決方案分解爲「客戶端」解決方案和「服務」解決方案的技術原因。但是，在我目前的工作中，我們確實將解決方案分成了兩個，因爲它是兩個獨立的團隊負責處理需求。所以，這純粹是我們的組織決定。
謝謝你。所以我認爲，在你看來，不同端點的主機和本地端（localhost：2020和localhost：2021）和CORS值得關注點分離。 – SB2055
絕對是。隨着項目越來越大，分離將很快得到回報。此外，使用不同的端點，您的消費者可以選擇直接轉到他們想要的（API或前端），而無需瞭解其他端點。 – vesuvious
另外，儘管CORS總是令人頭痛，但在webapi中編寫處理程序非常簡單。網上有大量的文檔用於編寫CORS處理程序，它允許您指定某些主機，所有主機等的訪問。 – vesuvious