2010-10-14 147 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。

所以基本上我的做法是:

  • 只允许项目,一个解决方案的范围内进行编辑(基本上是 - 决定谁“拥有”的项目)。
  • 将稳定副本复制/部署到位于实际解决方案/项目文件结构之外的中立位置,并引用这些共享代码的副本。
相关问题