我開始做很多的SharePoint開發較晚，和一些我已經做了，我不喜歡的東西是直接使用SharePoint Designer中的東西像頁面佈局，列出了定義，母版頁等 從我的觀點我認爲它更有組織地完成Visual Studio中的所有工作。通過這種方式，您可以將每個解決方案連接到源控制數據庫，並使用腳本更輕鬆地部署/收回/升級。你如何組織你的共享點發展？
我的想法是創建一個VS像這樣的解決方案：1。 對於一個列表和內容類型defintions。 2.一個用於webparts。 3.對於一個品牌
，但也許這種做法任何不利，你使用的是什麼其他辦法？
真正的答案是：它取決於。
我不認爲這是組織一個Visual Studio解決方案或SharePoint解決方案包一個最好的辦法。最後，你需要找到最適合你的組織的方式，並與之合作。
我見過的唯一指導是從SharePoint的在線文檔：
如果開發團隊正在設計需要超過10個WSP文件的解決方案，團隊應該重新考慮它的架構。在單個部署窗口中管理和部署如此多的WSP文件非常困難，而且由於SharePoint Online管理它的複雜性，該解決方案有被拒絕的風險。
大量的解決方案包（WSP文件），需要進行跟蹤和管理的構成進行部署一個挑戰。定製中的解決方案包越多，某些東西安裝不正確的可能性就越大，解決方案部署的時間越長，混合不兼容的解決方案包版本也越容易。我們建議客戶仔細檢查其部署計劃，並將解決方案包數量保持在項目所需的最低數量。請記住，解決方案包可以包含多個功能，因此不必爲每個功能部署一個解決方案包。
，我會同意這種看法。您似乎在單個SharePoint解決方案包中概述了3個Visual Studio解決方案和/或SharePoint解決方案包，以確定真正的3個功能。
我傾向於爲每個項目創建一個Visual Studio解決方案。對於非常大的項目，該單個Visual Studio解決方案可能包含多個項目，其中每個項目代表SharePoint解決方案包。
對於農場解決方案，每個SharePoint解決方案包都包含許多功能和應用程序相關的功能和文件。如果兩個或多個SharePoint解決方案包共享通用功能，我會將這些共享功能放入單獨的解決方案包中。
沙盒解決方案往往比農場解決方案小得多。雖然我的農場解決方案通常代表一個應用程序，但我的沙盒解決方案更專注於解決某個特定問題。所以我的沙盒解決方案通常只包含一個不依賴其他自定義功能或解決方案的功能。
正如我在開始時所說的那樣，我不相信有一條硬性或快速的規則。它通常取決於特定開發團隊的偏好和風格。一開始嘗試幾種不同的方式，最終你會發現最適合你的團隊。