[Spec] Define Design Patterns

[mandalorianbob]

Defining Design Patterns for MAUI

Currently, I've seen docs for Project MAUI mention repeatedly that they wish to support multiple design patterns, such as XAML with MVVM or C#-based UI with MVU.

This immediately led to someone posting that MAUI's proposed MVU isn't actually MVU but an MVU variant. I would also say that MAUI's proposed MVVM isn't really MVVM either. (I've noticed a tendency with some developers to take the attitude that every pattern can be a functional pattern if you try, and thus the "Model" in MVVM becomes "State" - but that's not what MVVM is: https://docs.microsoft.com/en-us/archive/blogs/johngossman/introduction-to-modelviewviewmodel-pattern-for-building-wpf-apps)

However, as other posters have noted, what MVVM or MVU are is not as important as what MAUI will be. Should they call them MVVM/MVU or "MAUI-VM/MAUI-VU" or something else entirely, I'm hoping for something far more important, something that as a XAML dev I've desperately wanted for a decade.

Definitions.

It is clear to me that at some point in the past the idea of "being opinionated" became some kind of weird taboo. Unfortunately, what this results in is a UI framework that's got a hodge-podge of ideas that is extremely kludgy to try to use except in a demo.

For instance, in UWP, by default, the View is responsible for Navigation. This doesn't really work in MVVM though, if the Navigation is the slightest bit non-trivial. This in turn results in a tremendous amount of work the moment you hit "File > New Project." Before you've even started to work on the actual app you want to make, you have boilerplate to write. This choice was made so "people don't have to use MVVM."

Navigation isn't a huge deal. Sometimes you can even get away without having any real logic in your navigation. But it's a fantastic example of the core problem. The core problem here is that a design choice in the framework was made so people "don't have to" use design patterns. And in almost every case in UWP, when this choice was made, it resulted in a framework that, while easy to make a demo with, was incredibly difficult to make an actual application with. Thus was born one of the most accurate descriptions of UWP: Easy to do the difficult things, and very hard to do easy things.

I'm obviously concerned that with MAUI, the exact same thing will happen, especially now that there's an emphasis on having multiple "supported" patterns. So I've opened this issue because I would like to see the design patterns that MAUI is going to use to be well-defined. This would include things like:

What is each aspect of the pattern, and what are their responsibilities? (Is the Model only state? Or is it business logic as well?)

Where do cross-cutting concerns live? (i.e. Navigation, security)

How much boilerplate is expected? (i.e. the INotifyPropertyChanged issue)

Is there an expectation that things can be done with _only_ the Page, and no backing code? (i.e. People shouldn't have to use the patterns)

How much abstraction is expected? How much of the framework can be mocked/swapped?

Can an app be made with SOLID principles?

I want to make clear here: I am not saying "this will be the only way things are done." I understand the desire to avoid a prescriptive framework, and to avoid inflexibility. But something I would point out is that, counterintuitively perhaps, trying to avoid inflexibility in UWP resulted in a remarkable lack of flexibility. Because of the reality of time constraints and maintenance, they didn't provide many ways to do something, they provided just one: the "simplest." Thus, easy to demo, very hard to make an app. To put another way, there will be an expectation for how the framework is used, whether implicitly or explicitly. I would just rather it be explicit, and well communicated.

So I think a good starting point would be "What do these words even mean in this context" the lack of which at the moment results in loads of crosstalk before even getting to the features. Because while no plan survives contact with the enemy, you really need a plan to deviate from.

Difficulty : high