Description
Problem Overview
The current aging MVC architecture in patch-hub
has grown increasingly fragile as new features have been added. The most critical architectural issue is that the system is evolving into a "big ball of mud" pattern where components become tightly coupled and responsibilities become blurred across the codebase.
The App struct serves as a central state manager that is becoming increasingly complex. This struct manages numerous responsibilities including screen state, API clients, configuration, logging, and various data collections, indicating a violation of the single responsibility principle at the architectural level.
These problems make it harder to maintain and test components.
Proposed Solution
The new architecture will have five components:
- The event handler
- App
- Model
- Viewmodels
- View
The two new characters are Viewmodel
s and View
s. These two traits will be used to separate the UI from the logic concerning the UI (while the Model
stores the overall business logic and data). To put it simply, a Viewmodel
is responsible for processing actions (such as add bookmark or send mail) that the user takes in the View
(which is essentially just the UI).
The App
will be the first and foremost struct initialized, holding general configuration and information about the app itself, such as the current screen, a collection of viewmodels and views. App
will also be responsible for drawing the screen/view.
After initializing and drawing the first screen, the event handler takes over. Any event is sent to the corresponding ViewModel for the screen (matched with the CurrentScreen
field in App
).
As always, if I left anything out or if anyone has any suggestions, please let me know!