C# 将数据服务调用放入助手类？

我有几个ViewModels，它们都做着部分相同的工作：del/add/export等文档。目前，调用这些方法的代码存在于viewmodels中。所以我必须复制/粘贴它。。。当我将代码放入DocumentHelper类中时，我只使用了一次，但是您是否看到反对从Helper类调用数据库方法的任何理由？

一个强调的是，您应该将代码移动到Helper类中

---

我坚信实用主义程序员的原则。这也是你应该努力遵循的。通过复制和粘贴代码，进行更改是一种令人讨厌的痛苦，因为您必须找到复制代码的每个地方并在那里进行更改。复制和粘贴技术粉碎了您可能拥有的任何敏捷性，使重构成为一场噩梦。

我想发表支持Travis G评论的评论，但我没有空间了——因此这是一个“答案”

您需要注意如何安排与依赖项相关的系统；请记住，您希望事物具有多大的可重用性。如果DocHelper引用了该模型，那么任何时候你想要重新使用DocHelper（比如在另一个应用程序中），那么你也必须使用该模型

两种可能的方法：

模型上下文中的“公共”对象位于模型部件中

MyApp.Model  // including Model Helpers
MyApp.Common // contains generic helpers

就参考而言，

模型

可以参考

通用

——但不能反过来

在模型上下文中“通用”的事物位于一个单独的程序集中，并且该程序集是一个专用的模型“助手”；真正通用的部件应位于单独的部件中，例如：

MyApp.Model
MyApp.ModelHelper // Model helpers are kept separate
MyApp.Common      // contains generic helpers

---

在这种情况下，

Model

将引用

ModelHelper

，而

Model

和/或

ModelHelper

可以引用

Common

+1我同意特拉维斯的观点；但还有一点-只需确保助手中没有任何视图/模型特定的代码/引用。我知道这是很明显的，但是在高亮度的灯光下并没有什么害处。当然：你们不能让不常见的东西变得普通。@Adrian好吧，我没有这个使用TBM.Model；在我的助手课上。这是对我的模型的一个“参考”，现在有那么糟糕吗？我将DocHelper设置为一个静态类。如果您在

DocHelper

中使用模型类也可以，只需确保您没有在

static

变量中存储任何内容-让您的函数使用它在参数中提供的内容，然后忘记它。这可能有一个CS词，但我想不起来。为了让您放心，让helper类

静态
是正确的做法。@Adrin“如果DocHelper引用了该模型，那么无论何时您想要重新使用DocHelper（比如在另一个应用程序中），您都必须使用该模型。”这是一个很好的评论，但我不认为我会在另一个应用程序中重复使用该代码，只是同一应用程序的另一个领域。错误的方法：模型可以引用DocHelper（但不能反过来）。