C＃开发工作的项目结构
您认为哪种目录/解决方案/项目结构对于用C＃编写的中型到大型项目来说是最易于管理和方便的？ “中到大”是指在具有嵌套命名空间的分层结构中包含各种Visual Studio C＃项目类型的项目。 1
我主要对Visual Studio 2008中“Windows”部分中的项目类型感兴趣：Windows窗体，WPF，两者的自定义控件和类库。 另外，我正在使用MSBuild（通过Visual Studio）来构建我的项目。
我从未发现Visual Studio自动生成的默认结构值得使用。 此结构有一个文件夹，仅用于包含解决方案和每个项目的嵌套文件夹。 我想知道这是否是因为我过去使用C＃的项目规模（从小到中）。 这个结构对大型项目有什么好处？ 你觉得它有用吗？
我也对文件夹名称及其与命名空间的关系等内容感兴趣。
以下是我个人的项目结构目标。
目标
- 每个项目都应该是完全独立的。 也就是说，我希望能够单独检查每个并编译它（在依赖项允许的情况下）。
- 导航结构应该很容易。
- 目录结构应以清晰直接的方式映射到名称空间。
- 识别解决方案文件应该很容易。
-
项目应该在很少或没有额外努力的情况下在Visual Studio（MSBuild）中在层次结构的大多数或所有级别上构建
- 请注意，除非明确指出，否则我在此处使用“项目”一词意味着“开发工作”。
我目前使用的结构是将整个系统拆分为逻辑部分，每个部分都是一个单独的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文件夹中。 通过这种方式，我可以在一个步骤中构建我当前正在使用的逻辑部分，并且还可以通过单击（或者，双击）构建完整系统。
在过去的一年半左右的时间里，我们在当前的项目中使用了这种结构，而且似乎运作得相当好。
您可以查看TreeSurgeon 。
对于C＃项目，我通常使用N层结构。 就像是：
/ projectname_interface_layer / / projectname_service_layer / / projectname_business_layer / / projectname_data_layer /
这具有在应用程序的不同实体之间提供清晰逻辑分离的优点。
我们所做的：
我们为每个层都有单独的解决方案，subversion存储库和构建。
每个层都有依赖关系构建，因此构建较低层将导致该层构建。
每个层都有一个Lib目录，其外部指向较低层的输出目录。
在构建之前，任何层（除了根层）都会对外部文件夹进行更新，从中提取最新的二进制文件。如果构建成功，则会将外部链接更新为最新版本，然后签入它自己的二进制文件。 这将触发链条的下一个构建，等等。
这样，较低级别层中的重大更改将无法构建链，但如果您从较高级别层获取，则它仍将在最近的function签入中起作用。
至于决定层，我们几乎有一个框架层，业务逻辑层和表示层（Web服务，应用程序或网站）。
至于测试，它们应该与他们测试的解决方案在同一个解决方案中，但是不同的组件。 绝不应将测试程序集部署到生产环境中。 原因是，如果不是经常，您将使您的测试程序集成为真正的“朋友”程序集。 假设攻击者可以在已部署的程序集上执行任何公共成员，则不仅可以访问实际代码上的公共成员，还可以访问内部成员。
此外，我们将与构建，工具，配置文件等相关的内容保存在自己的存储库中，与代码分开。