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

您可能想查看TreeSurgeon。

Answer 3

对于 C# 项目，我通常使用 N 层结构。比如：

/projectname_interface_layer/ /projectname_service_layer/ /projectname_business_layer/ /projectname_data_layer/

这具有在应用程序的不同实体之间提供清晰的逻辑分离的优势。

Answer 4

我们做什么：

我们为每一层都有单独的解决方案、颠覆存储库和构建。

每个层都有依赖构建，因此构建较低层将导致该层构建。

每一层都有一个Lib目录，外部指向下层的输出目录。

在构建之前，任何层（根层除外）都会对外部文件夹进行更新，将最新的二进制文件拉入。如果构建成功，则会将外部链接更新为最新版本，然后签入它自己的二进制文件。这将触发下一个构建链，等等。

这种方式下层中的破坏性更改将失败建立链，但如果您从上层获取它仍然会在最近的功能签入中起作用。

至于决定层，我们几乎有一个框架层、业务逻辑层和表示层（Web 服务、应用程序或网站）。

至于测试，它们应该与所测试的解决方案相同，但程序集不同。测试程序集应该永远部署到生产环境。原因是，通常（如果不是总是），您会让您的测试程序集成为真实程序集的“朋友”程序集。假设攻击者可以在部署的程序集中执行任何公共成员，这使他们不仅可以访问您真实代码中的公共成员，还可以访问内部代码。

此外，我们将与构建、工具、配置文件等相关的内容保存在自己的存储库中，与代码分开。