logo标签列表

什么是组织C#项目的最佳方式？

c#organization
9
我在想，你们是如何组织项目的，包括功能、范围等方面。
你是否有一个单独的项目用于单元测试，一个项目用于类库代码，一个项目用于用户界面？
或者你只是将所有这些分成不同的文件夹？
我认为按项目来分离它们更容易，因为你的核心代码库集中在一个地方，没有直接引用用户界面（没有WinForms依赖）或单元测试。
你有什么看法吗？
8个回答
17
我试着将项目分成可以称之为“部署单元”的部分。换句话说，“我应该如何部署这些程序集？”因为显然我不会部署单元测试，它们都在自己的项目中。
然后，我将UI和“业务逻辑”分别放在不同的项目中。如果我保持这些分离线路干净，我就可以用新技术或基础架构（比如WPF vs. ASP.NET）替换我的UI层，并仍然重用“业务逻辑”程序集。我只需引入一个了解业务逻辑接口的新UI层即可。
我还尝试保持一个单独的库，用于可能在解决方案之间共享的代码。这将是我的数据访问实用程序、文件解析实用程序以及其他我在构建项目时反复使用的实用程序。我只需要将这些程序集包含到我的新解决方案中，就可以获得我已经投入时间的所有功能。
希望这有所帮助。
4
我发现在解决方案中组织项目时，以下几种模式非常有用：
我几乎总是有一个“common”或“utils”项目。该项目应该具有非常少的依赖关系，因此可以轻松地在解决方案中任何地方重复使用（或可能在其他解决方案中重复使用）。您会惊讶于有多少小助手类将进入此项目。
我总是尝试将业务逻辑分离成一个项目（或更可能是一组项目），并将我的引导/提供者代码分离到另一个项目（或一组项目）中。我的引导/提供者类是特定上下文的（它们可以假设存在HttpContext或命令行参数等），但它们不包含任何业务逻辑。我的业务类实现业务逻辑，但不假设任何特定上下文元素的存在或缺失。这样，如果我最初将系统构建为控制台应用程序，则稍后可以编写一组Windows服务启动程序/提供程序，并且可以快速将其转换为Windows服务而对业务类产生最小或没有影响。
与引导/提供者类类似，我还尝试将数据层与业务类隔离开来。但这是一种常见的基本分离，每个人都听说过1000次，因此几乎不值得一提。
许多系统的业务逻辑过于复杂，无法放入单个项目中并保持代码可维护性。因此，我通常会有多个业务逻辑项目，按功能区域（“客户管理”，“产品库存”等）进行分组。
我还有一个utils文件夹，不是项目。里面有类图，可重复使用的类等。好建议！ - George Silva
3

我参与的最近几个项目 - 我们最终采用了以下结构（所有WPF Prism项目）：

  • xxx.Shell.Exe
  • xxx.yyyModule.dll（x 4-7）
  • xxx.Tests
  • xxx.Model
  • xxx.Common

对于使用WCF的项目，添加：

  • xxx.Backend
  • xxx.DataContracts

这些都在一个解决方案中（我们忍受着长时间的编译时间...）。将其分成单独的解决方案会在重构时引入太多问题。到目前为止，这对我们非常有效。

3

在一个解决方案中，我的项目通常包括以下几个部分：

Administration（管理）-- 一般是文档资料，许可证的主副本等。我通常还会将其编译成一个小型的命令行“自述文件”应用程序，以显示许可证、版本修订说明等。

Data（数据）-- 一般是像 XML 等的数据，没有可编译代码。

Library1... LibraryN（库1…库N）-- 一个或多个库（通常是 1-3 个：工具库、核心库、扩展代码库）。

Application1... ApplicationN（应用程序1…应用程序N）-- 应用程序（通常只有一个）。

Test1... TestN（测试1…测试N）-- 测试。

在每个项目中，我将每个命名空间的文件保存在单独的文件夹中，子命名空间则保存在子文件夹中，依此类推。像文档资料、库或应用程序特定的数据、嵌入式许可证文本等常见类型的内容，我会在具有相同名称的子文件夹中保存，无论该文件夹属于哪个项目。

-Neil

2
在Stack Overflow和Google上搜索一下，可能会有其他人问过同样的问题。
一些考虑因素：
当解决方案中包含多个项目时，使用Visual Studio编译需要更长的时间，比单个大型项目要慢。不要将解决方案拆分得太细。
微软的 组合应用指南 有一种有趣的项目划分方式。有一个基础设施项目，一个引导程序项目，以及每个代码“模块”的项目。
目前我正在开发一个与您的示例完全相同的项目：基础结构、业务逻辑、GUI和单元测试。
我更喜欢按照文件用途而非类型来组织文件。例如，我会创建名为“Communication”和“Interop”的文件夹，而不是“Events”和“Interfaces”。
1
你有一个项目用于单元测试，一个项目用于类库代码，一个项目用于用户界面吗？
基本上就是这样。通常将用户界面保持简洁，并将任何业务逻辑移动到自己的项目中，每个业务逻辑项目都有一个测试项目。
1

如果你正在开发一个带有用户界面的商业应用程序，那么你应该研究一下MVC。

当然，MVC只是一个通用概念，但它可以帮助你做出你现在面临的决策。

WPF中有很多关于MVC的资源，你可能也可以直接将其应用到WinForms上。

0

我按照您所描述的组装类型来分解项目。至少要有一个可执行的主项目（如果是应用程序）和一个或多个类库。如果是Windows应用程序，一定要尽可能地将UI与代码分离。WPF应用程序在实现这一点方面做得非常好。

除此之外，我可以提供的另一个建议是，当代码重用很明显或明显时，一定要收集一些第三方类库并编写自己的类库。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接