asp.net-mvc - 关于仅包含静态方法的“Helper/Utility”类的替代方案和建议

Question

当谈到 OOP 中的 Helper/Utility 类时，我有一个关于良好实践/原则的问题。

我在网上读到帮助程序/实用程序类是一种不好的做法，并且违背了 OOP 的含义（例如：This SO Question），但我无法找到这些类的有用替代方案。

我将更深入地解决我的问题，以说明我问这个问题的原因，希望能得到一些建议。我是一名新的软件开发人员，想要发展我对设计模式和实践的了解，因为开发的这一方面对我来说一直很重要（如何创建好的代码而不是正常工作的代码）。

我目前正在开发一个 ASP.NET MVC 应用程序。为简单起见，我将参考应用程序的前两个阶段，每个阶段都有自己的控制器。最初，Stage 1 的控制器有一堆从 SharePoint 检索列表的方法。我正在实现应用程序的新功能，现在需要第 2 阶段的控制器也从这些相同的 SharePoint 列表中检索信息。遵循DRY 原则，我不想在两个阶段的控制器类中包含这些方法。相反，我最初打算创建一个新的帮助程序/实用程序类，该类将包括所有这些（静态）方法，以从所有控制器可以使用的 SharePoint 列表中检索信息（有助于应用程序的未来促进代码重用）。

看到这些文章说这个助手/实用程序类违反 OOP 和反模式，我想就如何解决这个问题提出一些建议。

谢谢！

编辑

我已经意识到大多数人会想到的解决方案是将列表信息从阶段 1 的控制器传递到阶段 2 的控制器，但列表信息仅在特定场景中是必需的，只有在应用程序的阶段 2 期间才知道. 我想避免将列表信息从阶段 1 传递到阶段 2 的开销，并且仅在阶段 2 需要时访问 SharePoint 列表。

再次感谢！

标签： asp.net-mvcoopdesign-patternsobject-oriented-analysis