2010-10-14 29 views
3

我們在很好地組織解決方案時遇到了很多麻煩。我們有多個應用程序。他們是類似的應用程序,所以很多重用都完成了。不同的應用包含不同的功能,具體取決於我們不同的客戶將支付的費用如何爲多個應用程序組織.NET解決方案,項目和系統文件夾?

那麼,我們該如何組織事情呢? MSDN說,在下面的方式來組織:

SolutionFolder\ 
       Proj1Folder\ 
       Proj2Folder\ 
       Proj3Folder\ ... 

(注:解決方案文件夾,我的意思是系統,而不是一個Visual Studio解決方案文件夾中的實際文件夾。)

但沒有提到任何細節有關多重解決方案,重用項目。在第一個解決方案文件夾下創建第二個解決方案文件夾和參考項目是沒有意義的。我的第一個想法是完全隔離解決方案,然後根據需要參考項目。那有意義嗎?見下:

Solutions\ 
      Solution1.sln 
      Solution2.sln 
      Solution3.sln 
Projects\ 
     AFeatures\ 
        AProject1\ 
        AProject2\ 
        AProject3\ 
     BFeatures\ 
        BProject1\ 
        BProject2\ 
     CFeatures\ 
        CProject1\ 
        CProject2\ 

在上面的例子中,我已經基於某些功能分組項目。解決方案1可能包含功能A和C,解決方案2可能包含功能B和C,解決方案3可能包括A和B.事情變得更加複雜,因爲每個功能都可能具有不屬於所有解決方案的子功能。換句話說,可能有共同的AF特徵,但是更具體的A-1特徵,A-2特徵等。

最重要的是,我們還想將我們的項目組織在基於n層架構的基礎上。所以,我想我們會在中間添加BusinessServices,DataServices和UserServices文件夾。但是,將n層文件夾放在特徵結構的上方還是下方是否有意義?這是我的大腦開始旋轉的地方。

在類似的說明中,我們希望在不同的項目中實現我們的接口。這可能不是什麼大問題。我想我們會在同一目錄級別上有一個AInterfacesProject1和AProject,因此它們靠得很近。

我會很感激任何人對我的例子的評論。而且,如果您對我的同一問題有過經驗,我會很好奇你是如何組織它的。

回答

1

我可以告訴你的是我如何組織我的項目。

我有一個ASP.NET CMS /框架;這是由3個核心解決方案組成:

MyCode.Core (sln) 
    \MyCode.Core.Common (proj) 
    \MyCode.Core.BusinessLogic 
    \MyCode.Core.IDataprovider 
    \etc... 

MyCode.Core sln是我對這些項目進行任何(嚴重)開發的唯一地方。 我將成功的版本複製到磁盤上的「中立」位置。

包括在這裏的dll的這些項目的參考副本(MS Ent Libs,AntiXSS庫)。

接下來我有一個項目,它是一種「皮膚和模板」的SDK。

MyCode.Templates (sln) 
    \MyCode.Templates.Nasqueron (proj) 

該項目的輸出被複制到與核心相同的中立位置。 該項目引用MyCode.Core項目的輸出 - 特別是保存在中性文件夾中的項目。

最後我有web項目本身。我讓Visual Studio以它想要的方式來管理它。所有的參考資料都是複製到中立位置的dll。

所以基本上我的做法是:

  • 只允許項目,一個解決方案的範圍內進行編輯(基本上是 - 決定誰「擁有」的項目)。
  • 將穩定副本複製/部署到位於實際解決方案/項目文件結構之外的中立位置,並引用這些共享代碼的副本。
相關問題