在.NET项目中，你应该在哪里放置辅助类的一些最佳实践是什么？这里指的是与业务层不同的类，例如表示和应用程序相关的类，如appSetting配置管理器和其他有时可能是模块特定的代码，有时可能在整个应用程序中使用。
组织C#项目的辅助类或工具类
30
- spaghetticowboy
2
你能详细解释一下你所说的“辅助方法”是什么意思吗？可以举几个具体的例子吗？ - Jeff Sternal
@jeff 几乎任何可重用的代码。我通常都会有一个业务层项目，与呈现层分开，涵盖所有逻辑工作流项的功能。但是对于像配置设置包装器和实际帮助程序类之类的东西，例如构建请求、摘要查询字符串或在控件上执行常见函数的东西，我太懒了，不想扩展...那样的东西。我只是想知道处理所有这些的首选方式是什么。 - spaghetticowboy
6个回答
30
我通常允许此类事物相当灵活。 话虽如此：
- 我像测试其他类一样测试“helper”类。 这使它们不太可能是静态的。
- 如果我发现需要这些助手在多个类中使用，我会将它们移到它们自己的类或同一项目中的“Utilities”类中。
- 如果我发现这些助手在多个项目中都需要使用，则将其向上移动到“层次结构”中：从项目到解决方案，从解决方案到子系统，从子系统到应用程序，从应用程序到库或框架等。
- John Saunders
3
我倾向于采用Randolpho和Ben的方法：在“Utilities”命名空间的“Utilities”文件夹中使用静态帮助类。这样可以更好地组织文件，并使应用程序的其他命名空间保持清晰。
- monkeymindllc
2
我倾向于将它们放在一个 utils 的命名空间中。如果它们非常通用，例如 MyProject.Utils.MyHelperClass，则放在主项目命名空间中；如果它们更具体，则放在子命名空间中，例如 MyProject.CRM.Utils.MyCRMHelperClass。
- Ben Robinson
2
我几乎总是在我的解决方案中有一个名为MyProject.Core的类库，我将这样的内容放在其中。
编辑：我可能回答了一个“更大”的问题。
在单个项目中，这完全取决于项目的大小。Microsoft设计指南谈到，如果它包含少于五个类型，则不应创建命名空间（如果我对此数字有误，请纠正我）。
编辑：我可能回答了一个“更大”的问题。
在单个项目中，这完全取决于项目的大小。Microsoft设计指南谈到，如果它包含少于五个类型，则不应创建命名空间（如果我对此数字有误，请纠正我）。
- Jesper Palm
1
我们大多数人只是把它们放在“Helpers”文件夹中。
根据助手的不同，您可能希望将方法标记为虚拟，以便在必要时可以模拟它。或者绑定到它实现的接口，但如果每个接口只有一个具体实现，那可能会过度设计。
除非助手方法是纯计算且没有外部依赖，否则它们决不能是静态的。
即使是这样，请重新考虑。
- Randolpho
6
2@Randolpho，你为什么不将简单的辅助方法设置为静态的呢？那扩展方法呢？它们通常是辅助方法，但必须是静态的... - Wallace Breza
2@Nate Boss：因为如果你的静态帮助方法有外部依赖，当你使用静态方法时就会与该依赖紧密绑定。你无法模拟它，这使得你的代码更难测试和维护。 - Randolpho
@Wallace Breza：如果扩展方法属于纯计算类别，那么它们是完全可以的。 - Randolpho
1我完全理解测试静态方法的限制。我更想知道的是“即使如此，也要重新考虑”的部分... - Nate
1@Nate：这是一个指导性的规则。指导方针是“不要使用静态方法”。如果您认为静态方法可以解决问题，也许考虑使用可模拟的单例模式。 - Randolpho
@Nate 感谢您的回复 - 请问您在上面的评论中所说的“当你使用静态方法时，你与该依赖项紧密绑定。你无法进行模拟”是什么意思？我对这些最佳实践不是很了解，我正在创建一个带有方法的静态类以在必要时使用。非常感谢您的建议。 - BenKoshy
1
我们将这样的类放在一个名为Common的程序集中，该程序集旨在被所有需要它的项目引用，除非助手需要使用一些业务对象或核心对象。
- Eugene Cheverda
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接