2009-08-08 71 views
1

如何組織代碼,以便它可以輕鬆移植到業務項目中,而不會帶來不必要的膨脹?你如何構建可重用的庫?

例如(在.net),假設你有下面的命名空間:

namespace Computers 
    - Hardware 
     - Motherboard 
     - GPU 
namespace Monitors 
    - Display 
     - Mirrors 
namespace Peripherals 
    - USB 
    - PS/2 
  • 你創建每個父命名空間的項目,然後引用該項目的DLL中的其他項目?
  • 你是否創建了一個大型類庫並移植了這個東西(即使你只需要5%的庫)?
  • 或者,您是否只創建一個文件並將您需要的代碼複製到該文件中;把這個文件放在所有需要實現「即插即用」架構的項目中(儘管看起來很糟糕)?

編輯: 我不是在尋找對於.NET的答案明確,但它是我用具體的例子(因爲一個抽象的例子將使它更難理解在這種情況下的問題)

+2

您是否在尋找.Net答案?如果是這樣的話,你應該把它標記爲 – 2009-08-08 15:19:05

回答

2

你創建每個父 項目命名空間,然後引用 項目DLL在其他項目?

不一定。它通常以這種方式結束,因爲我的圖書館通常不是很大,但你會注意到微軟當然不會這麼做。即使您沒有包含System.Web引用,System.Web仍然存在。如果你這樣做,你會得到更多的課程。表明System.Web命名空間在幾個不同的DLL中使用。

你周圍建立一個大的類庫 和端口的事情(即使 你只需要在圖書館的5%)?

是的。硬盤空間便宜,比維護冗餘代碼便宜。

或者,你只是創建一個文件和 複製你需要的代碼到該文件; 將文件放在所有需要實現 「即插即用」體系結構的 項目中(就像看起來那樣是壞的 )?

這取決於功能。我通常會在片段中放置這樣的內容。例如,在我的Web項目顯示了一個典型的功能是一樣的東西:

void ShowErrorMessage(HtmlTableRow row, string message) 
{ 
    row.Cells.Clear(); 
    row.Cells.Add(new HtmlTableCell()); 
    row.Cells[0].InnerHtml = message; 
    row.Cells.Attributes.Add("class", "error"); 
    row.Visible = true; 
} 

它似乎從來沒有像一個很好的候選人的庫函數,因爲那時我不得不在CSS類,我想用它來傳遞偶爾還有細胞的價值。但是你會看到在我的Web項目的幾個地方坐着這樣的實現。

0

我將每個組件保存爲離散模塊,並使用Maven來管理我的依賴關係(它不僅適用於Java,請參閱此question,Byldan是一個.Net等效項)。

通過這種方式,您可以重複使用代碼,而無需將其包含在項目中。在上面的示例中,我可能會有三個工件,每個名稱空間都有一個工件,除非有充分的理由將它們放在一起(這有助於實現鬆散耦合)。

0

我最近發現,我試圖保持項目數量下降,如果只是爲了減少最終創建的實際程序集數量 - 我只是覺得在開發過程中更容易處理。這可能是因爲我發現很難創建真正模塊化且彼此獨立的項目。

我想一般的規則可能是:如果項目真的可以獨立於其他項目開發並插入其他項目而沒有任何其他依賴項,那麼將其作爲自己的項目。如果您發現總是需要引用其他項目才能使其工作(例如,可能在您的Monitors項目中,除非您還將計算機名稱空間與GPU類一起包含在內,否則根本沒有任何工作可行),那麼我會把它們放在一個項目中。

除此之外,我不認爲規則太硬和快。實際上取決於很多關於什麼的組件,這是很難做出任意的規則...

只是我的兩分錢,不值得了很多...

1

我從DNA中接受我的提示,並將我的一個龐大的類庫的全部或部分從項目複製到項目,即使我只在任何一個項目中使用1%的庫。我根據需要自由地重寫方法和類。

雖然這種方法有點違背傳統的編程智慧,但我不會認爲它:在過去的35億年裏它已經非常成功地用於生物。與生活一樣,替代方案(通過在整個項目中共享編譯程序集來鞏固界面和實現)抑制了變化並實際上保證了最終的滅絕。

+1

+1,但記住發生在恐龍身上的事情。 – Jem 2009-08-08 17:53:34

+0

你沒讀過侏羅紀公園嗎?恐龍的味道就像雞肉一樣。 – MusiGenesis 2009-08-08 18:09:43

0

我從一個單獨的dll開始,隨着它變得更大並開始包含一些相當獨立的組件,我可以選擇將它們分解爲單獨的dll。對我而言,這主要是一個美學問題 - 我喜歡讓事物獨立,正交和組織良好。考慮到現在可用的內存量和磁盤空間,一個大的dll沒有問題。

0

對於在多個項目中共享的東西,我通常會使用一個大的DLL方法。儘管如此,如果你有很多使用這個人的項目,我強烈建議你強有力地命名它並把它扔進GAC。隨着您添加越來越多的項目,您最終會遇到什麼問題,是希望對共享組件進行徹底更改。如果您沒有使用強大的命名/ GAC,那麼當您進行更改時,您必須更新每個應用程序,並且不可避免地會遺忘一個,生產中的某些內容將會爆炸。

嚴格命名它,在源代碼控制的集中文件夾中保留髮布版本,並始終引用該版本。然後將其部署在GAC中。