我在这里想知道，你们在功能，范围等方面如何组织你的项目。
您是否有一个单元测试项目，一个类库代码项目，一个用户界面项目？
或者您只是将所有这些分成不同的文件夹？
我认为通过项目分离这些更容易，因为您的中央代码库位于一个地方，没有直接引用UserInterface（没有WinForms依赖项）或UnitTests。
有什么意见吗？
答案 0 :(得分：14)
我尝试将项目划分为您可能称之为“部署单位”的项目。换句话说，“我如何部署这些程序集？”
因为我显然没有部署单元测试，所以他们在自己的项目中。
然后我将UI和“业务逻辑”划分为单独的项目。如果我保持这些分离线干净，我可以用新技术或基础设施（想想WPF与ASP.NET）替换我的UI层，并仍然重用两者的“业务逻辑”程序集。我刚刚介绍了一个了解业务逻辑接口的新UI层。
我还尝试为可能在解决方案之间共享的代码保留一个单独的库。这将是我的数据访问实用程序，文件解析实用程序，以及我在构建项目时反复使用的其他实用程序。我可以将这些程序集包含到我的新解决方案中，并获得我已投入时间的所有功能。
希望有所帮助。
答案 1 :(得分：4)
我发现一些模式在解决方案中组织项目时很有用：
我几乎总是有一个“普通”或“工具”项目。该项目应该具有非常少的依赖性，因此可以在我的解决方案中（或者可能在其他解决方案中）在任何地方和任何地方轻松地重复使用。你会惊讶地发现这个项目中会有多少小助手。
我总是试图将我的业务逻辑分成一个项目（或者更可能是一组项目），并将我的bootstrap / provider代码分成不同的项目（或一组项目）。我的引导程序/提供程序类是特定于上下文的（它们可以假定存在HttpContext或命令行参数等），但它们不包含业务逻辑。我的业务类实现业务逻辑，但不假设是否存在任何特定于上下文的元素。这样，如果我最初将系统构建为控制台应用程序，我可以稍后编写一组Windows服务引导程序/提供程序，并将其快速转换为Windows服务，对业务类的影响最小。 / p>
与bootstrap / provider类似，我也尝试将我的数据层与业务类隔离开来。但这是一个普遍的，基本的分离，每个人都听过1000次，所以几乎不值得一提。
许多系统的业务逻辑过于复杂，无法融入单个项目并保持一定程度的代码可维护性。因此，我经常发现自己有多个业务逻辑项目，按职能领域（“客户管理”，“产品库存”等）分组。
答案 2 :(得分：3)
我参与的最后几个项目 - 我们最终得到了以下结构（所有WPF Prism项目）：
xxx.Shell.Exe
xxx.yyyModule.dll（x 4-7）
xxx.Tests
xxx.Model
xxx.Common
对于那些使用WCF的人 - 添加：
xxx.Backend
xxx.DataContracts
一体化解决方案（我们使用较长的构建时间...）将其划分为单独的解决方案在重构时引入了太多问题。到目前为止 - 它对我们来说非常有用。
答案 3 :(得分：3)
我在解决方案中的项目方面做了类似的事情：
管理 - 一般文档，许可证的主副本等。我通常也会编译成一个小的命令行“自述”应用程序，显示许可证，修订说明等。
数据 - 一般数据，例如XML等。没有可编译的代码。
分享帮助 ... LibraryN - 一个或多个库（通常为1-3：utils，core，扩展代码）。
应用1 ... ApplicationN - 应用程序（通常是一个）。
测试1 ... TestN - 测试。
在每个项目中，我将每个命名空间的文件保存在单独的文件夹中，子文件夹中的子命名空间等等。我保留常见类型的东西，如文档，库或特定于应用程序的数据，嵌入式许可证文本等。，在与项目无关的同名子文件夹中。
-Neil
答案 4 :(得分：2)
在Stack Overflow和Google上进行一些搜索 - 还有其他人提出了同样的问题。
一些注意事项：
与单个大型项目相比，Visual Studio需要更长的时间来编译包含许多项目的解决方案。不要过分细分你的解决方案。
微软的Composite Application Guidance有一种划分项目的有趣方式。有一个基础设施项目，一个引导程序项目，然后是每个“模块”代码的项目。
目前我正在开发一个项目，将项目分开，就像您的示例一样：基础架构，业务逻辑，GUI和单元测试。
我更喜欢按目的组织文件，而不是类型。例如，我创建了名为“Communication”和“Interop”的文件夹，而不是“Events”和“Interfaces”。
答案 5 :(得分：1)
你有一个单位项目吗？ 测试，类库的一个项目 代码，用户界面的一个项目？
差不多这个。通常保持UI精简并将任何业务逻辑移动到自己的项目中，每个业务逻辑项目都有一个测试项目。
答案 6 :(得分：1)
如果您正在使用UI进行商业应用，则应该查看MVC。
当然，MVC只是一个普遍的概念，但它可以帮助你做出你现在所面临的那种决定。
WPF中有很多关于MVC的资源，你可以将它们直接应用于WinForms。
答案 7 :(得分：0)
如您所述，我按汇编类型拆分项目。至少有一个可执行的主项目（如果它是一个应用程序）和一个或多个类库是好的。如果它是一个Windows应用程序，一定要尽可能地将UI与代码分开。 WPF应用程序可以很好地完成它。
除此之外，我可以借出的其他一些建议肯定会收集一些第三方类库，并在代码重用明显或明显时编写自己的一些。