模型视图演示器被动视图实现

Question

目前，我正在使用.NET项目中使用C#的模型视图演示器被动视图。现在，在我的模型中，我有很多来自C/C++ DLL的Pinvoke。我的项目是一个硬件测试设备，典型的按钮和大液晶触摸屏。然后它收集数据(使用一些数据库)并传输到PC机。

我创建了一个模型接口，实现它的类调用那些Pinvoke方法。原因之一是我想在模型中封装inside和编组，互操作。

现在我有个主持人了。一个示例场景:用户按下一个按钮，视图上的click事件将调用演示器上的方法(通过接口)，然后最后调用模型的方法(再次通过接口)。

现在，在我看来，演示者似乎正在成为模型业务逻辑的包装者。如果我向模型添加了一些方法，我还需要通过接口添加该方法，因为视图的按钮需要调用模型中的一些方法。我觉得有太多的间接。一个例子是，在模型中，我有一个线程等待C/C++ DLL所推送的事件。现在，我在演示者上有一个线程，它使用观察者模式来排队和处理来自模型的事件(改变屏幕视图并告诉用户正在发生什么)。

伪代码从界面上看: void viewChangeTestResultsText(字符串文本)；

from the interface of presenter:
void PerformTest();

on the concrete class the implements the interface of presenter:
void PerformTest()
{
interfaceView.viewChangeTestResultsText("Test Started");
interceModel.PerformTest();
}

on the interface of Model:
void PerformTest();

on the concrete class of the Model:
PerformTest()
{
ModelPinvokeMethods.PerformTest();
}

在此代码中，按钮单击处理程序调用演示程序中的性能测试，然后演示者调用模型中的性能测试。然后，模型调用pinvoke性能测试。间接已经造成了一些痛苦，因为我有很多方法调用要实现，而且项目在一个非常紧迫的期限内。

对于我的项目，有另一个变体，我知道我将需要一个可改变的演示者，与此，我也需要一个可变的模型，因为业务逻辑在某种程度上是不同的，尽管有很多相似之处。现在，我正在考虑将模型中的所有逻辑推送给演示者，以便我只维护演示者视图上的逻辑，并且只将模型用于数据处理(数据库、配置、设置)，我认为这在开发和代码维护方面会更简单，但我不确定在灵活性方面的影响。

这是我第一次在被动视图中使用MVP。我不确定我是否遗漏了一些关于MVP正确实现的东西。对此有什么想法或建议吗？

Answer 1

您对MVP的理解似乎很好；您正确地区分了表示逻辑(执行测试、同步视图)和域逻辑(PInvoke)。通过设置的接口，可以轻松地对演示者进行单元测试(这是使用MVP的主要优点之一)。

我建议不要将所有的逻辑都放在演示者中，因为这可能导致上帝对象。

关于你变幻莫测的推荐人问题，我不知道你是什么意思。您的意思是每种类型的设备都需要不同的演示者/型号？如果是这样的话，对于每种类型的设备都有一个MVP-三位一体似乎是完全合理的，如果它们之间有足够的区别的话。如果确定它们之间的共同特征，则可以使用继承或实用程序类来提供通用代码。