Question

我们在很好地组织我们的解决方案时遇到了很多麻烦。我们有多个应用程序。它们是类似的应用程序，因此可以进行大量重用。不同的应用程序包含不同的功能，具体取决于我们不同的客户将支付的费用。

那么，我们如何组织事情呢？ 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.事情变得更复杂，因为每个特征可以具有不在所有解决方案中的子特征。换句话说，可能有常见的AFeatures，但有更具体的A-1特征，A-2特征等。

除此之外，我们还希望基于n层架构对我们的项目进行分组。所以，我想我们也会在中间添加BusinessServices，DataServices和UserServices文件夹。但是，将n层文件夹置于功能结构的上方或下方是否有意义？这是我的大脑开始旋转的地方。

在类似的说明中，我们希望我们的接口在不同的项目中实现。这可能不是什么大不了的事。我想我们在相同的目录级别有一个AInterfacesProject1和AProject，所以它们很接近。

我很感激任何人对我的例子的评论。而且，如果你有同样问题的经验，我会很好奇你是如何组织它的。

Answer 1

我可以告诉你的是我如何组织我的项目。

我有一个ASP.NET CMS / Framework;这由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项目的输出 - 特别是保存在中性文件夹中的项目。

最后，我有了自己的网络项目。我让Visual Studio以它想要的方式管理它。所有参考资料都是将dll复制到中立位置。

基本上我的方法是：

仅允许在一个解决方案的范围内编辑项目（基本上 - 决定谁“拥有”项目）。
将稳定副本复制/部署到位于实际解决方案/项目文件结构之外的中性位置，并引用共享代码的这些副本。

如何为多个应用程序组织.NET解决方案，项目和系统文件夹？

1 个答案: