组织 C# 项目帮助程序或实用程序类
在 .NET 项目中应该有哪些辅助类的最佳实践？指的是与业务层内容分开的类，但指的是表示和应用程序内容，例如 appSetting 配置管理器和其他代码，这些代码有时是特定于模块的，有时是在整个应用程序中使用的。
What are some best practices for where you should have helper classes in a .NET project? Referring to classes separate from business layer stuff, but presentation and app stuff like appSetting config managers and other code that would sometimes be module specific or sometimes be used throughout the app.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我总是让这样的事情变得非常流畅。也就是说：
I always allow things like this to be pretty fluid. That said:
我倾向于结合 Randolpho 和 Ben 的做法：我在 Utilities 命名空间的“Utilities”文件夹中使用静态帮助器类。更好的文件组织，使应用程序命名空间的其余部分保持清晰。
I tend to do a combination of what Randolpho and Ben do: I use static helper classes in a "Utilities" folder in a Utilities namespace. Better file organization, keeps the rest of the application namespace clear.
我倾向于将它们放在 utils 命名空间中。如果它们非常通用，则可以在主项目命名空间中，例如
MyProject.Utils.MyHelperClass，或者如果它们更具体，则可以在子命名空间MyProject.CRM.Utils.MyCRMHelperClass中。I tend to put them in a utils namespace. Either in the mainproject namespace if they are pretty general e.g.
MyProject.Utils.MyHelperClass, or if they are more specific then a sub namespaceMyProject.CRM.Utils.MyCRMHelperClass.我的解决方案中几乎总是有一个 MyProject.Core 类库，我在其中放置类似的内容。
编辑：我可能回答了一个“更大”的问题。
在单个项目中，这完全取决于项目的规模。 Microsoft 设计指南指出，如果命名空间中的类型少于五个（如果我对这个数字有误，请纠正我），则不应创建命名空间。
I almost always have a MyProject.Core class library in my solution where I put things like that.
Edit: I might have answered a "bigger" question.
In a single project it all depends on the size of the project. The Microsoft Design Guidelines talks about that you shouldn't create a namespace if you have less then five(correct me if I'm wrong about this number) types within it.
我们大多数人只是将它们放入“Helpers”文件夹中。
根据帮助程序，您可能希望将方法标记为虚拟，以便在必要时可以模拟它。或者绑定到它实现的接口，但如果每个接口只有一个具体的，那么可能就太过分了。
除非辅助方法是没有外部依赖性的纯计算，否则在任何情况下它们都不应是静态的。
即便如此，还是要重新考虑一下。
Most of us just throw them in a "Helpers" folder.
Depending on the helper, you might want to mark the methods virtual so you can mock it if necessary. That or bind to an interface it implements, but if you only have one concrete per interface it might be overkill.
Unless the helper methods are pure calculation with no external dependences, under no circumstances should they be static.
Even then, reconsider.
例如，我们将此类类放在名为
Common的程序集中，以便由所有需要它的项目引用，但助手需要使用某些业务对象或核心对象的情况除外。We put such classes in an assembly called
Commonfor example intended to be referenced by all projects which need it except of cases when helper need to use some buisness objects or core objects.