事件发生在我们的Model和ViewModel中，需要创建适当的View。问题是如何做到这一点并避免在VM或M中有任何View代码？
以下是事件的顺序，因此您可以看到这种困境：
用户在表单中设置一个数字字段以启动长时间运行的后台进程，然后单击“开始”按钮。如果这个长时间运行的过程成功，则需要弹出带有图形的图表以显示结果。但是，如果数据由于任何原因导致处理失败，则无法弹出图表，而是记录显示在表单上的文本框中的错误消息。
现在，该开始按钮调用ViewModel中实际启动后台线程的方法。
只有背景可以决定何时或是否创建视图。
目前，我们通过使用名为ChartInterface的接口来实现此目的。视图实现此接口，然后将回调委托一直设置为后端模型。当它决定创建Chart时，它会调用回调并使用该接口传递适当的数据等。
然而，这提出了一个问题，因为它可能会产生数十或数百个图表。因此，我们需要一个“仪表板”，其中包含所有图表的列表，供用户选择要查看的图表。
所以现在后端需要决定何时或是否要创建仪表板视图，然后向其中添加图表视图。
所以它变得越来越混乱，因为我们有很多需要视图的模型会有越来越多的这些情况，所以创建大量的回调委托会变得很难看。
似乎简化而不是大量回调的想法是仅将接口传递给ViewBinder到后端。然后每次创建一个模型对象时，它都可以将它传递给ViewBinder，以查看是否要将任何视图对象绑定到它。
我们的想法是，大多数任何后端对象都会很有趣（最终）以图形方式进行监控。因此，如果在构造之后将其中的每个人传递给ViewBinder接口，那么视图可以决定是否要将任何内容绑定到它。
这一直听起来更好。
答案 0 :(得分：0)
在处理代码时，答案变得清晰。
public interface ModelBinderInterface { void TryBind（对象模型）; }
而不是一个全局“服务器定位器”，每个视图对象实现此接口更自然。
然后，当它创建任何ViewModel对象时，它将自己分配给viewModel对象的ModelBinder属性。
现在，ViewModel可以将此相同的接口传递给后端进程。
当任何相关模型被实例化时，它就会用对象调用ModelBinder。
然后View对象可以决定它是否可以实例化该对象，如果没有，它可以将调用传递给它的父节点，它也实现了ModelBinderInterface。
这样每个视图都可以处理实例化视图，它理解是将控件添加到DataGridView还是将对象绑定到ListView等。
当然，这仍然允许单独的ModelBinder，因为较低级别可以继续将调用交给顶层应用程序ModelBinder，只有一个它可以提供单例实例。