实现MVVMC和依赖注入

我刚刚读了一篇关于MVC模式的文章。现在我有一个问题。控制器应该注入到ViewModel，还是ViewModel应该注入到控制器？

ViewModel是视图和控制器之间的契约，理想情况下也不需要知道（依赖于）

所以我肯定不会在ViewModel中注入控制器

---

我也不确定我是否会做相反的事情：控制器通常负责创建新的ViewModel实例。如果您想采用更松散耦合的实现，可以将抽象工厂注入控制器，以避免直接创建ViewModel类的新实例。

这取决于您正在做什么。我想大多数情况下控制器都不需要注入其中，但如果需要的话，在ViewModel中更可能需要它。让我解释一下

你用控制器干什么？你一定在做什么。。如果“某物”仅与“数据的外观”相关，则它属于视图。如果它与“向用户显示的内容”相关，则它属于ViewModel

我正在将一个控制器注入我的一个ViewModel中。我的ViewModel表示数据，然后在视图中绘制数据。我有一个命令，可以将数据项从当前图形移动到新图形。因为这改变了“图形窗口中显示的内容”，所以我在ViewModel中实现了该命令。ViewModel从其自己的项集合中删除数据项，然后使用控制器请求为该新数据创建新视图（它已经具有此功能）

看这篇文章，我没有看到控制器和视图之间的箭头

---

MVVMC只是一个MVC，其中视图被ViewModel对替换

• 利用基于XAML的技术中强大的数据绑定机制，视图仅与ViewModel交互
• ViewModel可以通知控制器，但不应注入控制器

---

我已经把一个简单的样本放在一起，基于众所周知的乔什·史密斯在MSDN上的样本。。。我已经介绍了一个控制器。

我认为控制器应该作为抽象IController注入。ViewModel需要IController才能导航到其他视图/ViewModel

例如，在ViewModel中：

IController _controller;

public MyViewModel(IController controller){
  _controller = controller;
}

void NavigateHome();
{
  _controller.NavigateHome();
}

抽象IController优于注入控制器本身，原因如下：

可测试性。可以插入模拟IController并测试ViewModel

脱钩。ViewModel不必知道控制器

我为在WPF中进行MVVMC开发了一个轻量级框架。 它与Asp.NET内核中的MVC有很多相似之处

如果您正在寻找WPF解决方案，请查看它

带有文档的博客帖子：

GitHub：

---

也许我很守旧，但你真的需要这种款式吗？我对作者在链接文章中提出的理由印象不太深刻。它似乎是为“如果”而不是违反雅格尼原则的“现在”编程。有些说法也有点极端。每当您添加另一个抽象层时（这只是我们讨论的UI层），解决方案的复杂性就会增加。我只是等待有MVVMCMVPVMVC的那一天…来画一个控件。ViewModel代码中的混乱情况如何？我想这取决于你如何定义“混乱”。通过添加控制器，您是否有特定的问题需要解决？@JordanParmer：在软件中，没有任何问题不能通过添加抽象层来解决。好吧，当然，期待太多抽象层的问题：）尽管Jordan可能会说服你，但这仍然是一个有趣的问题，当这个问题得到回答时，对社区是有好处的。但当我将控制器注入ViewModel时，它仍然是MVVM模式——事实上。控制器具有所有逻辑，这些逻辑（在一个控制器类中）提供给查看模型。控制器中注入了许多服务。这是错的吗？