Any architectural pattern you might suggest in order to keep data access separate from model?

[juandent]

Hi, It's me again, haha. I was wondering if you have a small sample where you keep the data access stuff (all that require initStorage()) separate from the model and view of the application. Or if you don't have a sample, maybe you can explain the architecture you use?

Best regards for a lovely library!!

[fnc12]

the simplest is MVC + Services. For example: LoginPageController contains LoginPageView and has a reference to a storage. Storage is one for one database and defined in main function (or a singleton if you don't care about unit-tests). Controller gets some data from a storage, next asks view to draw something that depends on this data. Next receives some user input and updates data. Storage service must know about data classes, it's ok. But data classes must not know about storage services/view/controllers cause there is no reason - data is passive. Controller contains logic and events handling. View has public functions like setUserNameLabelText(std::string) and showErrorDialog(std::string message)

[juandent]

I understand. Would it be accurate to state:

1. that the View does not see the model?
2. that the Model does not see the View?
3. that the Controller sees both the model and the view?
4. but who sees the controller? The View receives user input (like a mouse click or an edit to some text), thus it should be able to tell the Controller an interpretation of what that user input means. It seems to me that the View should therefore see the controller, to interpret user actions, but what about the Model? If the controller transfers user actions into model actions, the View will likely require updating. This can be done from the Controller sending a Refresh action to the View (accompanied by all the relevant data), so it seems the Model should not need to see the controller.

Is this correct?

You have no idea how much you are helping here!!

Regards

[fnc12]

view must not see the whole controller interface at least. To move implementation of user input from view to controller use either callbacks like std::function or an abstract class (an interface) like ViewDelegate which is inherited by controller and view must store a pointer/reference to it. If model is active (it means has some kind of logic implemented) so it may be unseen for controller. But if model is just a struct with several fields and that's all so controller must operate with model and next ask view to refresh. You can view this architecture implemented in my mitsoko-template repo in Core dir

[fnc12]

@juandent is the issue actual?

[juandent]

it is for now