我在这里想知道，你们是如何组织项目的，在功能、范围等方面。
您是否有一个用于单元测试的项目、一个用于类库代码的项目、一个用于用户界面的项目？
还是您只是将所有这些分成单独的文件夹？
我在想按项目分离这些更容易，因为您的中央代码库在一个地方，没有直接引用 UserInterface（没有 WinForms 依赖项）或 UnitTests。
有什么意见吗？
问问题
9915 次
8 回答
16
我尝试将项目划分为您可能称之为“部署单元”的部分。换句话说，“我如何部署这些程序集？”
因为我显然没有部署单元测试，所以它们在他们自己的项目中。
然后，我将 UI 和“业务逻辑”划分为单独的项目。如果我保持这些分隔线干净，我可以用新技术或基础设施（想想 WPF 与 ASP.NET）替换我的 UI 层，并且仍然为两者重用“业务逻辑”程序集。我只是介绍一个理解业务逻辑接口的新 UI 层。
我还尝试为我可能在解决方案之间共享的代码保留一个单独的库。这将是我的数据访问实用程序、文件解析实用程序以及我在构建项目时反复使用的其他实用程序。我只需将这些程序集包含到我的新解决方案中，就可以获得我已经投入时间的所有功能。
希望有帮助。
于 2010-07-16T17:55:39.127 回答
4
在解决方案中组织项目时，我发现了一些有用的模式：
我几乎总是有一个“通用”或“实用程序”项目。这个项目应该有很少的依赖关系，所以它可以很容易地在我的解决方案（或可能在其他解决方案）中的任何地方重用。你会惊讶于这个项目中有多少小助手类。
我总是尝试将我的业务逻辑分成一个项目（或更可能是一组项目），并将我的引导程序/提供程序代码分成一个不同的项目（或一组项目）。我的引导程序/提供程序类是特定于上下文的（它们可以假设存在 HttpContext 或命令行参数等），但它们不包含业务逻辑。我的业务类实现业务逻辑，但不假设存在或不存在任何特定于上下文的元素。这样，如果我最初将系统构建为控制台应用程序，我以后可以编写一组 Windows 服务引导程序/提供程序，并很快将其转换为对业务类影响最小甚至没有影响的 Windows 服务。
与引导程序/提供程序类类似，我也尝试将我的数据层与我的业务类隔离开来。但这是每个人都听过 1000 次的常见基本分离，所以几乎不值得一提。
许多系统的业务逻辑过于复杂，无法融入单个项目并保持一定程度的代码可维护性。因此，我通常会发现自己有多个业务逻辑项目，按功能区域（“客户管理”、“产品库存”等）分组。
于 2010-07-16T18:08:37.143 回答
3
我参与的最后几个项目 - 我们最终得到了以下结构（所有 WPF Prism 项目）：
xxx.Shell.exe
xxx.yyyModule.dll (x 4-7)
xxx.测试
xxx.型号
xxx.Common
对于那些使用 WCF 的人 - 添加：
xxx.后端
xxx.DataContracts
多合一的解决方案（我们忍受着漫长的构建时间......）将其划分为单独的解决方案在重构时引入了太多问题。到目前为止 - 它对我们来说效果很好。
于 2010-07-16T17:57:01.970 回答
3
我在解决方案中的项目方面是这样的：
管理——一般文档、许可证的主副本等。我通常也会将其编译成一个小的命令行“自述文件”应用程序，显示许可证、修订说明等。
数据——一般数据，例如 XML 等。没有可编译的代码。
Library1 ... LibraryN -- 一个或多个库（通常为 1-3：实用程序、核心、扩展代码）。
Application1 ... ApplicationN -- 应用程序（通常是一个）。
Test1 ... TestN -- 测试。
在每个项目中，我将每个命名空间的文件保存在单独的文件夹中，将子命名空间保存在子文件夹中等。我将常见类型的东西保存在无论项目如何，都具有相同名称的子文件夹。
-尼尔
于 2010-07-16T18:16:28.303 回答
2
在 Stack Overflow 和 Google 上进行一些搜索——还有其他人提出了同样的问题。
一些考虑：
与单个大型项目相比，Visual Studio 编译具有多个项目的解决方案所需的时间更长。不要将您的解决方案划分得太细。
Microsoft 的复合应用程序指南有一种有趣的项目划分方式。有一个基础设施项目、一个引导程序项目，然后是每个代码“模块”的项目。
目前，我正在开发一个项目，该项目就像您的示例一样划分项目：基础设施、业务逻辑、GUI 和单元测试。
我更喜欢按目的组织文件，而不是类型。例如，我创建了名为“Communication”和“Interop”的文件夹，而不是“Events”和“Interfaces”。
于 2010-07-16T17:47:43.967 回答
1
您是否有一个用于单元测试的项目、一个用于类库代码的项目、一个用于用户界面的项目？
差不多就是这个。通常保持 UI 精简并将任何业务逻辑移动到其自己的项目中，每个业务逻辑项目有一个测试项目。
于 2010-07-16T17:48:37.350 回答
0
如您所述，我按装配类型分解项目。至少有一个可执行的主项目（如果它是一个应用程序）和一个或多个类库是很好的。如果是windows应用，一定要尽量把UI和代码分开。WPF 应用程序在实现这一点方面做得非常出色。
除此之外，我可以提供的其他一些建议肯定是收集一些第三方类库，并在代码重用明显或明显时编写一些自己的类库。
于 2010-07-16T17:49:56.650 回答