我们在以良好的方式组织我们的解决方案时遇到了很多麻烦。我们有多个应用程序。它们是相似的应用程序,因此进行了大量的重用。不同的应用包含不同的功能,具体取决于我们不同的客户愿意支付的费用。
那么,我们如何组织事情呢? 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\
在上面的示例中,我根据某些功能对项目进行了分组。 Solution1 可能包括功能 A 和 C,Solution2 可能包括功能 B 和 C,Solution3 可能包括 A 和 B。事情变得更加复杂,因为每个功能都可以有子功能,这些子功能不会出现在所有解决方案中。换句话说,可能有共同的 AFeatures,但还有更具体的 A-1Features、A-2Features 等。
除此之外,我们还想根据 n 层架构对我们的项目进行分组。所以,我想我们也会在中间添加 BusinessServices、DataServices 和 UserServices 文件夹。但是,将 n 层文件夹放在功能结构的上方或下方是否有意义?这是我的大脑开始旋转的地方。
类似地,我们希望在实现的不同项目中拥有我们的接口(interface)。这可能没什么大不了的。我想我们会在同一目录级别有一个 AInterfacesProject1 和 AProject,所以它们靠得很近。
如果有人对我的示例提出意见,我将不胜感激。而且,如果您遇到过与我相同的问题,我会很好奇您是如何组织它的。
最佳答案
我只能告诉你我是如何组织我的项目的。
我有一个 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 项目的输出 - 特别是保存在中性文件夹中的输出。
我终于有了 Web 项目本身。我让 Visual Studio 按照它想要的方式管理它。所有引用都反对将 dll 复制到中性位置。
所以基本上我的方法是:
- 只允许在一个解决方案的范围内编辑项目(基本上 - 决定谁“拥有”该项目)。
- 将稳定副本复制/部署到实际解决方案/项目文件结构之外的中立位置,并引用共享代码的这些副本。
关于.net - 如何为多个应用程序组织 .NET 解决方案、项目和系统文件夹?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3936189/