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 Viewmodels and Views. 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!
Problem Overview
The current aging MVC architecture in
patch-hubhas 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 two new characters are
Viewmodels andViews. These two traits will be used to separate the UI from the logic concerning the UI (while theModelstores the overall business logic and data). To put it simply, aViewmodelis responsible for processing actions (such as add bookmark or send mail) that the user takes in theView(which is essentially just the UI).The
Appwill 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.Appwill 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
CurrentScreenfield inApp).As always, if I left anything out or if anyone has any suggestions, please let me know!