How Do I develop .NET MAUI apps

As you can see in those images, which showcase the project structure of my 2 latest apps I typically have the same structure in every project. This is what works for me and now I will explain that in further detail.

First all folders marked violet are preexisting for every new MAUI project. The blue folders are additional things i don’t need every time. Typically the Helper folder is for storing Converters and stuff like. the others are specific to the apps. One could argue that BottomSheets should be part of the views and he would be right. I can’t actually remember why I separated that.

Where I figured out the best way for me is with the red marked folders. Much of that has to do with the architectural pattern that I use, which is called MVVM (Model–view–viewmodel). This explains the 3 main red folders of Models, Views/Pages and ViewModels. The addition I made, which I think is not that common, is the Services folder. But what do those terms even mean in the first place? General definition coming:

MVVM (Model-View-ViewModel)

MVVM is a design pattern used primarily for building user interfaces that separates the concerns of data (Model), user interface (View), and the logic that connects them (ViewModel). This separation offers several benefits like improved testability, maintainability, and code reusability.

Components

• Model: Represents the data and business logic of the application. It is responsible for fetching, storing, and manipulating data. It has no direct knowledge of the View or ViewModel.

• View: The user interface that displays data from the ViewModel and allows the user to interact with the application. It is typically implemented using XAML or HTML and has no direct knowledge of the Model.

• ViewModel: Acts as an intermediary between the Model and the View. It prepares data from the Model in a way that is easily consumable by the View. It also handles user interactions and updates the Model accordingly. It has no direct knowledge of the View.

How it works together

The View observes the ViewModel for changes, and the ViewModel observes the Model. When the Model changes, the ViewModel is updated, which in turn updates the View. User interactions in the View trigger commands in the ViewModel, which then updates the Model. This ensures that the Model, View, and ViewModel remain loosely coupled, making the application easier to develop, test, and maintain.

Example

Imagine a simple application that displays a list of customers.

• Model: Would be responsible for fetching the customer data from a database or API.

• View: Would display the list of customers in a user-friendly way, perhaps using a list or grid.

• ViewModel: Would retrieve the customer data from the Model, format it for display (e.g., sorting, filtering), and expose it to the View.

This separation of concerns allows developers to work on different parts of the application independently, improving productivity and reducing complexity.

Now I’ll explain how I use this for developing my apps and which changes/additions I made. Concerning Views and ViewModels I just use them as in the definition explained. Her I have no further things to add.

Concerning the Models tho I have quite a different approach. I personally use Models as pure definitions of the Data they hold meaning they are quite stupid and just hold data instead of for example fetching or manipulating it. Those are the tasks that the Services do in my applications. Below I have two pictures showing exactly that. For the model you can see that it clearly only defines the structure of the data without doing anything. The service on the other hand is able to talk to the appstore api and use that model to purchase a subscription for example.