C#开发工作的项目结构

Question

您认为哪种目录/解决方案/项目结构对于用C#编写的中型到大型项目来说是最易于管理和方便的？"中到大"是指在具有嵌套命名空间的分层结构中包含各种Visual Studio C#项目类型的项目.¹

我主要对Visual Studio 2008中"Windows"部分中的项目类型感兴趣:Windows窗体,WPF,两者的自定义控件和类库.另外,我正在使用MSBuild(通过Visual Studio)来构建我的项目.

我从未发现Visual Studio自动生成的默认结构值得使用.此结构有一个文件夹,仅用于包含解决方案和每个项目的嵌套文件夹.我想知道这是否是因为我过去使用C#的项目规模(从小到中).这个结构对大型项目有什么好处？你觉得它有用吗？

我也对文件夹名称及其与命名空间的关系等内容感兴趣.

以下是我个人的项目结构目标.

目标

• 每个项目都应该是完全独立的.也就是说,我更愿意能够单独检查每一个并编译它(在依赖项允许的情况下).
• 导航结构应该很容易.
• 目录结构应以清晰直接的方式映射到名称空间.
• 识别解决方案文件应该很容易.

• 项目应该在很少或没有额外努力的情况下在Visual Studio(MSBuild)中在层次结构的大多数或所有级别上构建

  1. 请注意,除非明确指出,否则我在此处使用"项目"一词意味着"开发工作".

Answer 1

我目前使用的结构是将整个系统拆分为逻辑部分,每个部分都是一个单独的Visual Studio解决方案.每个这样的解决方案都包含在文件夹结构中,如下所示:

[logical part name]
  |-doc
  |-lib
     |- // any non-GAC-assemblies needed by the projects in the solution
  |-src
     |-Production
     |  |-Project1
     |  |-Project2
     |-Tests
        |-UnittestProject1
        |-UnittestProject2
  |-tools
     |- // any tools needed for automated builds and such 
        // (NUnit, NCover, MSBuild tasks, ...)

这确实需要一些文件移动(例如,一个逻辑部分的输出需要被移动到另一个部分的lib文件夹中,但是这可以在MSBuild脚本中轻松实现).我们还有这样一个MSBuild脚本,它按顺序调用每个逻辑部分的MSBuild脚本,并将输出移动到适当的lib文件夹中.通过这种方式,我可以在一个步骤中构建我当前正在使用的逻辑部分,并且还可以通过单击(或者,双击)构建完整系统.

在过去的一年半左右的时间里,我们在当前项目中使用了这种结构,而且似乎运行得相当好.

Answer 2

对于C#项目，我通常使用N层结构。就像是：

/项目名称_接口_层/ /项目名称_服务_层/ /项目名称_业务_层/ /项目名称_数据_层/

这样做的优点是在应用程序的不同实体之间提供清晰的逻辑分离。