將項目拆分爲多個項目的原因？

Question

將開發項目（如ASP.NET MVC應用程序）拆分爲多個項目的常見原因是什麼？代碼組織也可以通過文件夾完成。多個項目傾向於產生循環引用衝突，並且通過必須管理/解決這些衝突而增加複雜性。

那麼，爲什麼？

Answer 1

一種可能性是有一個系統，給定組（或單顯影劑）可在代碼的其餘部分的獨立工作的。另一個是將系統其餘部分需要的常見實用程序代碼分解出來 - 例如錯誤處理，日誌記錄和常用實用程序。

當然，只是想在一個特定的函數/類/文件，其中的邊界是藝術的問題，而不是科學所發生的時候。

Answer 2

擁有一件事。如果你有開發人員負責代碼庫的不同部分，那麼分裂項目是自然而然的事情。人們也可以通過功能來分割項目。這減少了衝突和複雜性。如果增加，那隻意味着缺乏溝通，你只是做錯了。我能想到的

Answer 3

一個例子是，你可能會在發展，你最終開發這可能是更普遍的使用，這不愧是自己的項目庫一個項目找到。例如，也許你正在製作一個視頻遊戲，並且最終你會寫一個音頻庫，但它絕不是專門與遊戲項目相關聯的。

Answer 4

部分原因是

封裝 - 通過包裝一組例程的另一個庫中，無論是作爲一個靜態庫或一組DLL的，它變成一個黑盒子。因爲它是一個很好的黑匣子，所以你需要做的就是確保你給出正確的輸入並獲得正確的輸出。它有助於您重新使用該庫。它還強制執行某些規則和防止黑客編程（「嗯...我就作出這樣的成員函數公共現在」）

減少了編譯時間 - 磁帶庫已遵從;你不必在編譯時重建它，只需鏈接它（假設你正在執行C++）。

解耦 - 通過包住你的類到一個獨立的庫，可以減少耦合，可以重複使用其他目的的庫。同樣，只要庫的接口不變，您可以對庫進行所有更改，而鏈接到庫或引用它的其他人則根本無需更改其代碼。 DLL在這方面很有用，不需要重新編譯，但如果許多應用程序安裝不同版本的相同DLL，可能會很棘手。您可以更新庫而不會影響客戶端的代碼。雖然您可以對文件夾執行相同的操作，但沒有明確的機制來強制執行此操作。

此外，通過實施具有不同圖書館的這門學科，還可以確保你所寫的內容是通用的，從實現分離。

許可/商業化 - 嗯，我認爲這是很明顯的。

Answer 5

1. 代碼重用。假設您有項目A，並且您啓動了一個新的項目B，它具有許多與項目A相同的功能。將A的共享部分拉出並使它們成爲可供A和B使用的庫這允許你在兩個地方都有代碼，而不必在兩個地方維護相同的代碼。

2. 代碼重用，倒置。假設您有一個在一個平臺上運行的項目。現在你想讓它在兩個平臺上工作。如果可以分離出與平臺相關的代碼，則可以爲每個依賴於平臺的庫啓動不同的項目，然後使用不同平臺的不同庫編譯中央代碼庫。

Answer 6

不是質疑多個組件中代碼的價值，而是質疑在一個地方聚集所有代碼的價值。

你會把你的廚房裏的東西放在一個櫃子裏嗎？

循環引用是循環引用，無論它們是在程序集之間還是在它們之間發生。違規組件的設計很可能是次優的;通過裝配避開組織可以諷刺地阻止編譯器爲你檢測情況。

我不明白你可以像使用項目一樣對文件夾組織代碼。如果那是真的，我們的操作系統就不會有獨立驅動器的概念;他們只會有一個巨大的文件夾結構。高階組織模式表達與簡單文件夾不同的意圖。

項目說「這些概念是密切相關的，只與其他概念有關。」

Answer 7

這裏有一些很好的答案，所以我會盡量不重複。

將代碼分解到自己的項目的一個好處是在多個應用程序之間重新使用程序集。

我喜歡上面提到的功能性方法（例如庫存，運輸等都可以獲得自己的項目）。另一個想法是考慮部署模型。層，層或服務器之間共享的代碼可能應該在它自己的通用項目中（或者如果期望更好的控制，則可以是項目集合）。專用於某個層級的代碼可能在其自己的項目中。例如如果您有單獨的Web服務器和應用程序服務器，那麼您不希望在應用程序服務器上部署UI代碼。

拆分的另一個原因可能是一旦應用程序在生產中就允許小型增量部署。假設您遇到需要修復的緊急生產錯誤。如果小改動需要重建整個（一個項目）應用程序，那麼您可能很難對質量保證小測試周期進行調整。如果您只部署一個具有較小功能集的程序集，則可能會更容易銷售。