组织 c# 项目助手或实用程序类

Posted 2023-02-22

【中文标题】组织 c# 项目助手或实用程序类

【英文标题】：Organizing c# project helper or utility classes

【发布时间】：2011-03-22 22:03:15

【问题描述】：

对于在 .NET 项目中应在何处使用帮助程序类，有哪些最佳实践？指的是与业务层的东西分开的类，而是表示和应用程序的东西，如 appSetting 配置管理器和其他有时是特定于模块或有时在整个应用程序中使用的代码。

【问题讨论】：

您能否详细说明“辅助方法”的含义，或许可以举几个具体的例子？

@jeff 几乎所有可重用的代码。我通常总是有一个与表示层分开的业务层项目，它涵盖了逻辑工作流项的所有功能。但是对于所有的东西，比如配置设置包装器和实际的帮助器类，比如构建请求、摘要查询字符串，或者在控件上执行常用功能，我懒得扩展......那是那种东西。我只是想知道处理所有这些的首选方式是什么。

【参考方案1】：

我总是允许这样的事情变得非常流畅。也就是说：

我测试“助手”类与任何其他类相同。这使得它们往往不是静态的。 我可以先在需要时将这些帮助程序创建为单独的方法。由于我发现不止一个类需要它们，因此我会将它们移到自己的类或同一项目中的“实用程序”类中。 如果我发现在多个项目中都需要它们，那么我将它们在“层次结构”中上移：从项目到解决方案，从解决方案到子系统，从子系统到应用程序，从应用程序到库或框架等.

【参考方案2】：

我的解决方案中几乎总是有一个 MyProject.Core 类库，我在其中放置了类似的东西。

编辑：我可能回答了一个“更大”的问题。

在单个项目中，这完全取决于项目的大小。 Microsoft 设计指南谈到，如果命名空间中的类型少于五个（如果我对这个数字有误，请纠正我）类型，则不应创建命名空间。

【参考方案3】：

我倾向于将 Randolpho 和 Ben 的做法结合起来：我在 Utilities 命名空间的“Utilities”文件夹中使用静态辅助类。更好的文件组织，保持应用程序命名空间的其余部分清晰。

【参考方案4】：

我们大多数人只是将它们放入“Helpers”文件夹中。

根据帮助程序，您可能希望将方法标记为虚拟，以便在必要时模拟它。那个或绑定到它实现的接口，但如果每个接口只有一个具体的接口，它可能是矫枉过正的。

除非辅助方法是没有外部依赖的纯计算，否则在任何情况下它们都不应该是静态的。

即便如此，请重新考虑。

【讨论】：

@Randolpho，你为什么没有简单的帮助方法作为静态方法？扩展方法呢？它们通常是助手，但必须是静态的......

@Nate Boss：因为如果您的静态辅助方法具有外部依赖项，那么当您使用静态方法时，您将紧密地绑定到该依赖项。你不能模拟它，让你的代码更难测试和维护。

@Wallace Breza：如果扩展方法属于纯计算范畴，那么它们是非常好的。

我完全理解测试 staic 方法的局限性。我更想知道“即便如此，重新考虑”位......

@Nate：这是指导性规则之一。指导方针是“不要使用静态方法”。如果您认为静态方法可以解决问题，不妨考虑使用可模拟的单例。

【参考方案5】：

我倾向于将它们放在 utils 命名空间中。如果它们非常通用，则在 mainproject 命名空间中，例如MyProject.Utils.MyHelperClass，或者如果它们更具体，则为子命名空间MyProject.CRM.Utils.MyCRMHelperClass。

【参考方案6】：

我们将这些类放在一个名为 Common 的程序集中，例如，旨在供所有需要它的项目引用，除非助手需要使用一些业务对象或核心对象。