Separation of Logic and UI - Does the orchestration belong in the model?

Question

I wrote an app with the MVP Passive View pattern.

My solution has four different projects. A MyApp.Core containing all kind of business logic, a MyApp.Forms containing stuff related to WinForms (UI), a MyApp.Tests contain all unit and integration tests and a MyA0p.Xamarin containing stuff related to XamarinForms (UI).

Of course my idea was to make as much code reusable as possible. Since I use the MVP Passive View Pattern I managed to do that pretty well. All my App.Core needs to be constructed are some implementations of view interfaces (and some other stuff that is not important here). So my Constructor looks similar to Core.MyApp(IFirstView view, IOtherView other,...). I thought this approach is cool. In theory my app does not need to know whether it is an Xamarin, Console or WinForms application, all it needs are implementations of some view interfaces. That way I was even capable of testing an implementing navigation inside my core project, i.e. which view interface is shown and a first in first out view stack behavior. So my WinForms application is really dumb. It just has one root form and two user controls that implement IFirstView and IOtherView and that's it. Cool.

Now I started to use Xamarin. The start was similar. I set up all view pretty fast and it is working on the fly. But now there are so many small UI things that look not that great and need to be touched. All these things are Xamarin related and sometimes it's hard to fix that in Core or hard to even fix that in Xamarin.Forms since a lot Xamarin functionally was moved to Core.

So now I wonder if my approach was correct at all? Did I put too much in my Core project? Should UI orchestration better be placed in the UI projects?

Thanks in advance for any suggestions!

Answer 1

In your description of the project, you mention using the MVP pattern and you talk about the MyApp.Core and various View components. What i am missing is the Presenter part of the MVP pattern.

This is also where you took a wrong turn: you seem to have merged the Presenter and Model parts into one component: MyApp.Core.

In the MVP pattern, the Model part should be completely oblivious about the existence of a View part. You have nicely decoupled the implementation of the View, but the Model should not even know what information gets shown in which View.
It is the task of the Presenter part to arrange the connection between the Model and the View. And in doing so, the Presenter can have knowledge of the technology used to implement the View, while the Model should not have that knowledge.