0
votes

I'm currently using Model View Presenter Passive View on my .NET Compact Framework project using C#. Now, in my model, I have lots of Pinvoke from a C/C++ DLL. My project is a hardware testing equipment, typically with buttons and large LCD touchscreen. It then collects data (uses some database) and transfer to PC.

I created a model interface, and the class that implements it invokes those Pinvoke methods. One reason is I would like to encapsulate the Pinvoke and marshalling,interop inside the Model.

Now I have a presenter. An example scenario: a user presses a button then the click event on the view will call the method on presenter (via an interface), then finally call the model's method (via an interface again).

Now, it seems to me that the presenter is mostly becoming a wrapper of the model's business logic. If I add some methods to the model, I also need to add that method via an interface because the view's button's need to invoke some of the methods in the model. I feel that there is too many indirection. One example is that, in the model, I have a thread to wait for the events being pushed by a C/C++ DLL. Now, I have a thread on the Presenter which uses an observer pattern to queue and process that events coming from the model (changing of screen views and telling the user what is happening).

pseudo code from the interface of view: void viewChangeTestResultsText(string Text);

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();
}

in this code, the button click handler calls the performtest in the presenter, then presenter calls the performtest in the model. then model calls the pinvoke performtest. the indirection quite causing some pain already because I have lots of method calls to implement and the project is in a very tight deadline.

For my project, there is another variant and I know that I will be needing a changeable presenter and with this, I also need a changeable model because the business logic is somehow different although there are lots of similarities. Right now, I am thinking of pushing all the logic in the model to the presenter so that I will just be maintaining only the logic on the presenter view and use the model only for data handling (database, configurations, settings), which I think will be simpler in terms of development and code maintenance but I am not sure of the impact in terms of flexibility.

This is my first time to use MVP in passive view. I am not sure if I am missing something regarding the correct implementation of MVP. Any thoughts or suggestions on this?

1

1 Answers

1
votes

Your understanding of MVP seems fine; you have correctly distinguished between presentation logic (perform test, synchronize view) and domain logic (PInvoke). With the interfaces you have set up, you can easily unit test the presenter (which is one of the main advantages of using MVP).

I would advise against putting all of the logic in the presenter as that can lead to a God Object.

Regarding your changeable presenter problem, I'm not sure what you mean. Do you mean that you need a different presenter/model for each type of device? If so it seems perfectly reasonable to have a MVP-triad for each type of device if they are sufficiently distinct from one another. If you identify common traits between them, you can either use inheritance or utility classes to provide common code.