我们正在开展一个非常大的VS项目。
我们希望项目结构能够“暗示”开发人员对逻辑组件进行设计。
为此目的,这是最好的:
答案 0 :(得分:1)
我的项目非常庞大。
我们将不同程序集中的每个“模块”分开,创建类库。像这样:
Client.ProjectName (Solution)
Client (Class Library)
- SectionHandler...
- ComponentModels...
- Utilities...
Client.Web (Class Library)
- Handelrs
- Extenders
Client.Net (Class Library)
- MailQueue
Client.Blog.WebControls.UI (Class Library)
- TopContent.ascx
- PostsList.ascx
Client.News.WebControls.UI (Class Library)
- TopContent.ascx
- PostsList.ascx
Client.Website
每个Class Library
都是解决方案Client.ProjectName
下的项目或其他一些共享解决方案。
文件系统如下所示:
Client
|- Framework
|- Client
|- files...
|- Client.Web
|- files...
|- Client.Net
|- files...
|- SolutionName
|- Client.Blog.WebControls.UI
|- Client.News.WebControls.UI
|- Website
共享客户端库直接位于Client\Framework
文件夹下,它可用于此客户端的所有项目。具体项目属于解决方案。我们还有一个名为Company
的文件夹,我们保存可以在任何其他项目中用于任何客户的项目,就像公司框架一样。
我们使用的解决方案:
可以在多个解决方案中引用相同的项目,因此您不一定需要创建所有这些解决方案。
使用这种格式,我们可以在其他项目中使用很多东西,只需引用DLL。没有这种结构,某些项目在给定的时间内是不可能的。
答案 1 :(得分:1)
解决方案只是项目的容器,所以它实际上是有问题的项目的分裂。
我建议为每个主要功能区域使用不同的项目(AKA类库或程序集)。您可能仍希望在每个项目中使用不同的命名空间,但将主要功能区域分成不同的程序集将使每个程序集更小。因此,如果您只需要在应用程序中使用一个或两个函数,则只能引用这两个项目而不是一个大型项目。这将使较小的应用程序编译得更快,开销更少。
就解决方案而言,您可以根据需要组织这些,因为就像我说的那样,它们只是容器。您可能希望将它们全部放在一个解决方案中......或者每个解决方案中的每个解决方案......或者可能将相关项目放入解决方案中。就个人而言,我使用一个解决方案,或者对于大型项目,我使用“主”解决方案,这样我就可以轻松地一次性编译所有内容和单独的解决方案,这样我就可以单独处理项目。
答案 2 :(得分:0)
我越来越喜欢使用包含关键域的子文件夹的单个解决方案,并在其中添加项目。它易于浏览,并为您的开发人员提供了一个粗略的想法。
如果eigther解决方案中的组件之间的集成是松散的,那么拥有多个解决方案非常有用,因此每个团队都有自己的工作解决方案,并针对其他团队解决方案中的已发布组件进行测试。
答案 3 :(得分:0)
项目应该是您重复使用的“原子”。或者换句话说,项目是可重用代码的粒度。拥有相互依赖的项目是可以的,但每个项目都应该被计划为对自己的功能有用。
解决方案就是开发/构建/测试所需的任何项目集合。您可以使用多个解决方案来指定不同的项目子集。
项目中的文件夹可能有所帮助,但它们可能表明您的项目变得太大了。
解决方案文件夹同样意味着您的解决方案可能会变得太大。您能否将代码库划分为多个解决方案,每个解决方案都具有有意义且可测试的输出工件?解决方案可以依赖于来自其他解决方案的(测试的)工件,就像它们在第三方库等上一样。
您还应该考虑VS和解决方案项目如何映射到版本控制架构上的项目粒度以及您拥有的任何分支/合并策略。