一個大中型項目的結構

我是一個初學者程序員，對任何愚蠢道歉。一個大中型項目的結構

來自python背景創建只有幾個類的小項目，我會在大部分時間將所有的代碼放在一個文件中。

我最近一直在學習c＃，並且正在寫一個相當大的控制檯應用程序（10,000行+）。我顯然不能將所有內容都放在一個文件中，但我不確定如何將項目分成更小的片段。

到目前爲止，我完成這項工作的方法是爲我的解決方案中的每個名稱空間創建一個新項目，並將每個類相應地拆分爲單獨的文件。到目前爲止，我有大約四個命名空間。我已經獨立編寫了每個名稱空間，以便在其他項目中使用每個名稱空間。

我現在正在舞臺上，我想拼湊每個命名空間來構建我的控制檯應用程序。我如何去做這件事？

另外，我是否以正確的方式構建我的代碼？

+ 1，是否可以使用位於項目內完全不同目錄中的文件？

非常感謝提前。

來源

2012-04-16 Sherlock

如果您可以對項目進行全面的概述，我想我們可以告訴您更多。目的是什麼？它是某種進口工具，或者其他什麼。也許有人知道一個開源項目應該有類似的結構（即使它有不同的目的），你可以看看它們是如何解決它的。代碼組織沒有銀彈，這一切都歸結爲優先選擇和一些可維護性的最佳實踐。根據目的分離是一個很好的做法;-) – 2012-04-16 18:49:21

如果您接受其他一些問題的答案，人們將更有可能迴應這一問題。 – 2012-04-16 18:49:28

@Erik - 這是一個由神經網絡（顯然），訓練遺傳算法，CSV閱讀器，數據前/後處理器和迴歸分析組成的神經網絡。每個人都在自己的名字空間內。 – Sherlock 2012-04-16 18:56:38

當你開始一個命名空間，您通常會使用您的公司或組織名稱（如「A」）。如果您有多個產品/項目並且正在爲該項目創建代碼，那麼您需要添加限定符（比如說「B」，「C」等等，這樣您將擁有A.B，A.C等）。

然後一般的方法是，你想在相關的命名空間中將類型組合在一起。如果您創建了一個類型，並且它是常見問題的通用/實用/一次性解決方案，則您需要將其保留在範圍更廣的名稱空間中。當你發現你創建了許多類型來支持某些功能或用途時，你可能希望創建一個狹窄的名稱空間來包含這些類型。例如，假設您需要爲A.B編寫幾個數據訪問組件，其中包含數據傳輸對象，數據訪問對象等。然後，您可能希望將這些類型放入類似於A.B.DataAccess的內容中。

但是，請記住，.NET使用OOP範例。一個OOP範例是代碼重用。因此，如果您在A.B和A.C中訪問數據，那麼您將很好地創建可重用的數據訪問組件，以鼓勵兩個項目中的代碼重用。在這種情況下，您可能希望有一個像A.Common這樣的項目，其中包含您的任何產品使用的常見類型，其中包含可用於AB，AC等的一般用途，通用或抽象概念。

讓我試着進一步研究這個例子。

項目：A.Common（集會名）
用途：可重複使用的類型對任何項目
命名空間：A，A.DataAccess
類型：A.DataAccess.DataAccessObjectBase

項目：AB（組件名稱）
目的：A.Commmon
命名空間：對於產品「B」
參考文獻類型A，AB，ABDataAccess
類型：ABDataAccess.DataAccessObject（實現A.DataAccess.DataAccessObjectBase）

項目：AC（集會名）
目的：爲類型產品「C」
參考文獻：A.Common
命名空間：A，AC，ACDataAccess
類型：ACDataAccess.DataAccessObject（實現A.DataAccess.DataAccessObjectBase）

這是一個非常簡單和原始的例子，但希望它將幫助您可視化程序集和命名空間之間的關係。

一些其他提示：

不要與創建命名空間太過火，創造深命名空間（如A.B.Something.SomeMoreStuff.EvenMoreStuff）特別是當，除非是明智的。它使你找到事情有點困難。
命名空間應該從更廣泛的目的到更狹義的目的。此外，如果您在更廣泛的命名空間中使用的命名空間較窄的名稱空間中創建類型，請務必將其放在更廣泛的命名空間下。例如A.B.Broader.Narrower。

最後，您應該繼續爲每個源文件創建一個類型。

來源

2012-04-16 19:15:33 HackedByChinese

這已經清理了我的東西，非常有用的信息 - 非常感謝:) – Sherlock 2012-04-16 19:22:25

非常好的答案！ – 2012-04-16 23:42:12

我將從上一個問題開始到第一個問題。您可以使用位於項目中完全不同目錄中的文件。我認爲你以正確的方式前進。關於不同的命名空間，您可以使用此代碼

using System; 
using namespace1; 
using namespace2;

來源

2012-04-16 18:44:21 Likurg

是的代碼我可以說更多 – Likurg 2012-04-16 18:52:41

聲音或多或少在正確的軌道上。解決您的問題/結構：

1）不需要讓每個唯一的名稱空間由其自己的項目表示;如果它有助於組織你的課程，你可以（也可能應該）在同一個項目中有多個子命名空間。就你而言，這聽起來像每個人都被編程爲自己的獨立組件，因此每個項目都是合理的。

2）你將每個類拆分成一個單獨的文件是好的，繼續這樣做。

3）不確定你在詢問如何將代碼拼湊在一起。你是指如何去物理引用/鏈接Visual Studio中的項目或最佳實踐來編寫/訪問你的API？如果是前者，可以右鍵單擊項目下的「引用」項並指向該項目（而不是其編譯的DLL）。如果後者存在各種可以遵循的編程模式，但通常您會希望從項目中抽象出一個很好的API，這樣您就不會擔心代碼的內部工作。

4）你完全可以從一個完全不同的目錄引用文件。只需右鍵單擊項目或文件夾，選擇「添加 - >現有項目」，然後瀏覽到該文件。你可能想將其添加爲一個「鏈接」，因此它並不是物理複製文件：http://msdn.microsoft.com/en-us/library/9f4t9t92%28VS.80%29.aspx

這裏的另一個StackOverflow的疑問，雲比特到可能的解決方案結構：Solution: Per application, or per application suite

來源

2012-04-16 18:58:32

非常好，謝謝你的迴應，幫助很多 – Sherlock 2012-04-16 19:00:53

一個大中型項目的結構

回答

相關問題