我正在爲Xamarin開發一款適用於iOS，Android和Windows手機的應用程序，並且對架構有疑問。從他們的網站：Xamarin架構項目或命名空間
而且從示例解決方案所提供：
他們把業務層，數據訪問層，並在同一個項目中的數據層。
但在此之後，當他們解釋的體系結構：
封裝：[...]這意味着，UI代碼（例如）應該只負責顯示畫面並接受用戶輸入;並且從不直接與數據庫交互。 [...]
和：
[...]代碼分離成層使應用程序更容易理解，測試和維護。建議在每一層中的代碼是物理上分離（無論是在目錄或者對於非常大的應用甚至獨立的項目），以及邏輯上分離（使用命名空間）。[...] （重點煤礦）
如果他們在單獨的項目上不會更好嗎？我的意思是，如果它全部在同一個項目中，並且我在UI層中引用此項目，那麼我可以直接訪問業務層和數據層，但我不知道這是否正確。
的問題是：
這是可以接受的（和接受），在層與目錄分開？
用目錄和命名空間或者項目來分離圖層會更好嗎（或者最接受）？
，那豈不是更好，如果他們是在不同的項目？我的意思是，如果 所有它在同一個項目中，並且我在UI 圖層中引用此項目，那麼我可以直接訪問業務層和數據層 ，我不知道這是否正確。
....
這是可以接受（和接受），於層與 目錄分開？
用目錄 和命名空間或項目分離層是更好的（或最容易接受的）？
關於你的第一個問題：沒關係。假設你將每個圖層分成一個獨立的項目（這意味着你爲每個項目獲得一個程序集）。正如你所指出的，你仍然可以從更高的層次訪問那些較低層的代碼。應用程序分層的原則只是說一層中的代碼不能引用更高層中的代碼 - 它確實是而不是阻止您訪問堆棧中「更深」的代碼。防止這種情況的唯一邊界是「層級」邊界 - 這是更正式的（並且更加昂貴）。
關於第二個問題：當然，如果你願意，你可以這樣做。但這不是強制性的。您當然可以擁有分層架構，而不必將每個圖層拆分爲子文件夾/名稱空間。有時甚至可能阻礙。對於一些設計哲學（如某些形式的DDD），最好使用名稱空間來分組垂直要素，而每個圖層的各個類都位於相同的要素名稱空間內（通常使用類命名約定來標識圖層） 。
關於第三個問題：除非您有充分的理由，否則我不會將圖層分成項目。 「很好的理由」包括：在應用程序之間共享代碼，黑盒風格的單元測試，或防止開發團隊在大型系統中發生衝突，其中開發團隊擁有整個系統的一部分，代碼需要合併到更大的主線控制流程與正式驗收檢查點。
我肯定不會爲了分層而將代碼拆分爲更多的項目。每個額外的項目都會增加構建過程的開銷。在某個時候，IDE將開始窒息（儘管通常情況下，直到你在解決方案中獲得大約30個左右的項目）。
實際上，絕大多數移動應用程序不會很大或很複雜，無法證明對這個主題有太多的想法。如果您的項目足夠大，您正在考慮沿層邊界將其拆分，那麼可能是時候退一步，重新考慮範圍。
這個問題沒有正確的答案。分離關注通常被認爲是一個很好的設計目標;然而，您在多大程度上和/或如何實施將因項目而異。對於Xamarin提供的許多示例項目，它們不夠大，無法證明分解爲單獨的Data/Domain /等項目是合理的。
我在第一個問題中提到了這個問題根據項目的特點，以任何形式分離圖層是可以接受的。問題在於知道項目必須具備哪些特性，以某種方式進行分離。 –
正如傑森正確指出的那樣，以及與大多數設計決策一樣，這取決於。
只是幾件事情需要考慮：
的開裂項目
分裂的測試按文件夾
到目前爲止所有的答案都讓我看到，項目中的圖層並不總是必須的。我只能接受一個是可惜的。 –