正在查找静态帮助程序类的替换项
本文关键字：替换 帮助程序 查找 静态 | 更新日期: 2023-09-27 18:20:31
我有一个MVC ASP.NET项目，目前我使用一个静态ViewModelHelper类，该类有几个方法（每个视图模型1个），这些方法接受某些参数和模型对象，并为我生成视图模型对象，以便我从控制器返回到视图。它们目前都是静态的，类作为一个整体是无状态的，我只是在想实例化视图模型的实例时使用它，因为有些数据需要相当复杂的逻辑。
这些方法作为视图模型类中的构造函数会更好吗？我的理解是最好不要在视图模型中有任何逻辑，但我可能错了。或者，我应该在这里使用一种设计模式来帮助我创建这些视图模型吗？
这是项目的体系结构和设计的问题，ViewModels应该是什么样子，以及应该在哪里/如何初始化它们。现在看来，您的ViewModels是DTO，您可以使用工厂方法对它们进行初始化。这很好，但我建议实际接受抽象的工厂模式，并确保工厂实现不会因不相关的责任而过载。这是"实用程序"类的继承问题，应该让每个开发人员都保持警惕。
另一方面，视图相关的初始化逻辑，例如填充选择列表，可以很好地位于ViewModels本身中。在这种情况下，你应该警惕重复。
另一种可能的方法是使用构建器模式。
如果你只使用任何一种方法，而不是混合搭配，那么这两种方法都可以是一种干净的解决方案。当然，只要你保持清洁。）
在没有看到这种相当复杂的逻辑的情况下，我建议您检查一下为什么初始化逻辑一开始就那么复杂。如果真的必须这样的话。也许一些商业逻辑偷偷潜入了那里？
ViewModels应该只是DTO，只包含属性的类。没有逻辑。将逻辑放入其他类（取决于服务或完整的业务逻辑）中，并让它们填充ViewModel。
我知道，相对于实质性的设计考虑，这个答案似乎很短，但这是它的核心。为了进行推理等，请查看一些成熟的ASP.NET MVC解决方案来演示它，比如https://prodinner.codeplex.com/.