2011-09-25 26 views
6

好的,這已經在我腦海中一段時間​​了。我正在爲所有常見的中間層對象創建可重用的公司命名空間(類庫)。這個程序集可以在開發階段被我們的開發人員引用。這是我的問題。創建一個由所有中間層邏輯組成的單個組件還是將此功能分解爲更小的組件更爲可接受?創建可重複使用的公司命名空間的最佳實踐

示例:單個組件中(命名空間的例子)

系統

System.IO

System.IO.RegEx

System.Net

System.Net。 Mail

System.Security

的System.Web - AssemblyFull.dll

實施例:多個組件

System.IO

System.IO.Reg - 編譯爲AssemblyIO.dll

System.Net

System.Net - 編譯成AssemblyNet.dll

在過去,我已經這樣做了使用這兩種方法,但我不知道其他人一樣,爲什麼?我不在尋找任何代碼示例,我只想知道其他開發人員在做什麼?

在此先感謝。

+0

如果它只包含所有內容,程序集將有多大?您是否期望貴公司的項目能夠使用所有常用功能?如果不是的話,你是否可以在邏輯上將它分解成相關的子單元(這可能是放入不同程序集的好候選)? –

+0

Google for reuse/release equivalence principle – driushkin

+0

Richard - [full]程序集將由100個對象組成。大多數項目總是會使用75%-85%的功能,但仍然可以使用其他部分。我最初的想法就是像你所說的那樣處理這個問題。拿最廣泛使用的物體,並建立一個共同的議會,然後採取其他對象,並將其分成單獨的單位。但另一方面,我可以看到單個程序集如何讓其他開發人員的生活更輕鬆。你只需要引用中間層程序集並完成它。我有一種感覺,這是6到1半到另一個 –

回答

4

作爲一般規則,我用它來分開程序集,如果它們沒有顯式耦合。例如,如果您有一個低級別的網絡API,以及其他用於FTP相關操作的API,則後者可能取決於前者;但對於API用戶,您的開發人員;沒有必要在一個單一的組件中都有;也許一個項目不需要FTP API,因此他們只需要包含核心「Net」程序集。您可以分離API,以便儘可能更原子化,並避免開發人員在僅使用其中很小一部分時包含大集合。

這種方法的缺點是,如果開發人員需要FTP組件,他們也需要包含網絡;所以你必須找到一種方法來管理那些降低開發人員複雜性的依賴關係。我在使用Java應用程序時使用Maven (from Apache),但到此日期我不知道maven-like alternative for .NET

但是,如果您正在爲您的公司構建一些API,請使用Wiki站點或其他輕量級文檔工具來解決此問題。

+0

洛倫佐 - 感謝您的快速反應。這是我第一次聽說Maven,聽起來很酷。我越想打破我的對象就越有意義。儘可能將它們分開。如果其中一位開發人員需要訪問電子郵件功能,那麼確實沒有理由讓密碼對象可見/可訪問。感謝所有快速反應的人,我非常感謝他人的意見。另外我知道我不是星期天唯一工作的人。 –

+0

@lorenzo NuGet(www.nuget.org)與.NET上的Maven近距離接觸 – x0n

+0

@xOn Tks,我將評估Nuget ... –

1

我不認爲他們是一個正確的答案,但我傾向於爲我們所有的圖書館使用通用的命名方法。

我有一個庫處理大量的中間層功能,有點像大多數應用程序使用的常見任務。

Web.CreditCard
Web.CreditCard.Authorization
Web.CreditCard.Charge
Web.CreditCard.Batch

Web.Store.Order
Web.Store.Entities
Web.Store。車
Web.Store.Auth

Web.User.Auth.OpenID
Web.User.Auth.OAuth
個 Web.User.Account
Web.User.Preferences

所以這並不重要項目的類型你的建築,你可以重新使用它們,並確定他們的真快。其中一些具有自己的接口,可以繼承和重載,以根據項目需求添加更多功能。

+0

這幾乎就是我所看到的在我們的倉庫中。我只是想讓其他開發者儘可能簡單。我將繼續推進一個常用程序集,該程序集將用於所有項目,然後爲不常用的功能分離程序集。感謝所有那些很快回到我身邊的人,我真的很感激。 –

0

感謝大家回答了這個問題。由於每個項目都不同,幾乎不可能提出正確的答案,所以我會描述我將如何處理這個問題。

第一:

我需要確定哪些業務/中間層對象會在前進的所有項目中使用。一旦這些已經確定,我會。常見或[公司]創建裝配[公司] .common.util。這些將被用於我們目前和即將開展的項目。

二:

找出特定項目多的對象。這些組件可能會或可能不會被引用。一個例子是[company] .security.cryptography

三:

確保每個對象是有據可查的,這樣以後的開發人員必須正確維護所需的知識和引用正確的組件。

我想感謝大家很快回到我身邊。這是我的第一篇文章,但我可以向你保證,你很快就會再次見到我。再次感謝。

+1

我不喜歡在名稱空間內使用公司名稱,我曾與Verizon以及Verizon的許多名稱空間一起工作。[名稱]現在該公司的大塊不再被命名爲Verizon,但它仍然有那個名字空間在那裏。 –

+0

有效的點。我通常會使用公司名稱,因爲我們通常會執行某種形式的集成,以便更容易地識別程序集的來源。如果你正在創建一個通用命名空間,你會用什麼作爲你的頂級? –

0

我對可複用文件使用了不同的方法。

我創建一個單獨的解決方案,包括可重複使用的所有組件,測試等

每個可重複使用的「事物」(類,函數,用戶控件,圖標等)是在一個單獨的文件中。

需要來自可複用部分的一些功能的項目直接鏈接到源文件。 (「添加現有項目」,「添加爲鏈接」)。爲了方便起見,我把所有的再使用零部件在VS一個「工具」文件夾(真正的實用工具文件夾爲空,因爲文件鏈接)

此設置允許我:

  • 只需添加常用功能我需要
  • 沒有額外的依賴公用事業
  • Bug修復被自動列入未來建設

唯一的缺點是,如果你需要手動添加任何DEPE附加功能獲得的屬性(例如另一個可重複使用的部件或組件)

由於我不使用不同的組件中,命名空間只是如下功能:

  • Company.Utilites
  • Company.Utilites.WPF
  • Company.Utilites .IO