在 .NET 项目中应该有哪些帮助类的最佳实践是什么？指的是与业务层的东西分开的类，但表示和应用程序的东西，如 appSetting 配置管理器和其他有时是特定于模块或有时在整个应用程序中使用的代码。
问问题
26263 次
6 回答
23
我总是允许这样的事情变得非常流畅。那说：
- 我测试“助手”类与任何其他类相同。这使得它们往往不是静态的。
- 我可能会在需要时将这些帮助程序创建为单独的方法开始。由于我发现不止一个类需要它们，我会将它们移到自己的类或同一项目中的“实用程序”类中。
- 如果我发现在多个项目中都需要它们，那么我将它们在“层次结构”中向上移动：从项目到解决方案，从解决方案到子系统，从子系统到应用程序，从应用程序到库或框架等。
于 2010-07-29T19:42:48.993 回答
2
我的解决方案中几乎总是有一个 MyProject.Core 类库，我在其中放置了类似的东西。
编辑：我可能已经回答了一个“更大”的问题。
在单个项目中，这一切都取决于项目的大小。Microsoft 设计指南谈到，如果命名空间中的类型少于五个（如果我对这个数字有误，请纠正我）类型，则不应创建命名空间。
于 2010-07-29T19:10:58.030 回答
2
我倾向于结合 Randolpho 和 Ben 所做的事情：我在 Utilities 命名空间的“Utilities”文件夹中使用静态帮助程序类。更好的文件组织，保持应用程序命名空间的其余部分清晰。
于 2010-07-29T19:57:06.043 回答
1
我们大多数人只是将它们放入“Helpers”文件夹中。
根据帮助程序，您可能希望将方法标记为虚拟，以便在必要时对其进行模拟。那个或绑定到它实现的接口，但如果每个接口只有一个具体的接口，它可能是矫枉过正的。
除非辅助方法是没有外部依赖的纯计算，否则它们在任何情况下都不应该是静态的。
即便如此，请重新考虑。
于 2010-07-29T19:10:14.357 回答
1
我倾向于将它们放在 utils 命名空间中。如果它们非常通用，则在 mainproject 命名空间中MyProject.Utils.MyHelperClass，或者如果它们比子命名空间更具体MyProject.CRM.Utils.MyCRMHelperClass。
于 2010-07-29T19:10:54.077 回答
1
我们将这些类放在一个名为的程序集中Common，例如旨在由所有需要它的项目引用，除非助手需要使用一些业务对象或核心对象。
于 2010-07-29T19:37:33.397 回答