如果我創建一個大的C＃應用程序，我應該讓這一切在一個項目？
我打算有一個數據層和GUI層。這些應該在一個項目中，還是應該分成兩個項目？在這個階段，我認爲它應該都在一個項目中，因爲你可以有一個單獨的代表數據層的類文件夾，並在需要時實例化它們。
比方說，我曾經爲數據層單獨的項目，應該這個項目（因此DLL）中調用？我不會稱之爲<ProductName>_DataLayer.DLL。你從來沒有看到。
是否還有其他重要問題？重要的是要保持主要.EXE的大小？
你應該把這些層作爲單獨的項目，例如相同的解決方案中的數據層將是一個類庫項目，它可能被命名爲YourProjectName.DAL例如ProductName.DAL.DLL或數據層
數據和GUI分離始終建議，你永遠不知道將來你需要怎樣處理數據層。
我使用。數據.UI命名約定，和它的罰款。
我肯定會在自己的項目中保留單獨的圖層。根據應用程序的大小，我還建議您考慮將其進一步分解爲基於功能的邏輯分組。
你可以任意調用它。您可以將程序集名稱設置爲與項目的「屬性」窗口中的項目名稱不同。
你必須做出的代價是你是否想重用多個項目之間的數據層。如果答案是肯定的，那麼你應該把它放在一個單獨的項目中。
如果沒有，它仍然可能是明智的，它從GUI分開只是以防萬一的場景的時候，您沒有想到的。 （例如，你決定創建一個web服務）
命名： 我喜歡數據和用戶界面的命名約定。
如果解決方案變得非常大，您可以考慮使用'解決方案文件夾'。
更簡單的方法是將所有項目放在同一個解決方案中。
但是，如果您有很多項目 - 很久以前創建並且未修改的項目（或者修改是罕見的） - 最好將它們從解決方案中排除，將DLL移動到某個常用文件夾並使用作爲解決方案的dll引用。
對於名字我們使用點隔開 - 例如<項目> .dal。dll
同一個解決方案中的不同項目是一個很好的方法，但真正取決於項目的使用方式。
在一個點上它是共同具有ProjectName.UI> ProjectName.BLL> ProjectName.DAL架構，然後創建一個模型項目定義數據合同在層之間移動數據。
BLL =業務邏輯層 DAL =數據訪問層
每一層被編譯成不同的組件，具有用於您的接口的EXE。編譯後的EXE的大小並不是一個真正值得關注的問題，但更多地獲得正確的體系結構 - 如果每層都有單獨的項目，它將使您的部署更易於管理。
現在使用Repository模式體系結構更爲常見，該體系結構很適合使用ORM。你想要可測試的，基於組件的代碼很容易開發和重構你應該使用存儲庫。
我在話題個人收藏：Scott Hanselman，Mike Roberts
）粘到我使用.Presentation該UI的.NET圖案，.Persistence用於邏輯數據層和。邏輯。 – TomTom