Model-View-Presenter diagram of an app

[kirlat]

This issue is to discuss role of existing components within the MVP diagram of an application and what changes can be made to fit components into it better.

The text below is taken from: https://github.com/alpheios-project/documentation/issues/38#issuecomment-680029584 @balmas: Stepping back to look at the overall architecture framed according to the philosophy outlined at https://khalilstemmler.com/articles/client-side-architecture/introduction/ here's what I think it looks like (the core library -- I'm not trying to represent the client applications of alpheios core here)

I think, at least according to this architecture approach, are model and presenter layers are not separate enough, and within the model, there isn't much clean separation of concerns between interaction and infrastructure.

[kirlat]

I think it's a very good and useful diagram. It helps to understand where each component does fit (or does not).

I have a few comments:

1. I think L10n messages themselves belong to the data model. It's a translation data that is stored in memory (i.e. in an "in-memory database"). L10n data module is a controller that provides an API to retrieve translation data. Its place is probably within the Data Fetching in the Model layer.
2. The UI Vue Modules are controllers and should probably be on top of the UI controller. Data and Support Vue models, I think, belong to the Data Fetching and should stay where they are.

On my opinion, we should modify the UI Controller to be on the Presenter level, and the App Controller - on the Model level only.

@balmas, @irina060981: please let me know what do you think.

[balmas]

I think L10n messages themselves belong to the data model. It's a translation data that is stored in memory (i.e. in an "in-memory database"). L10n data module is a controller that provides an API to retrieve translation data. Its place is probably within the Data Fetching in the Model layer. The UI Vue Modules are controllers and should probably be on top of the UI controller. Data and Support Vue models, I think, belong to the Data Fetching and should stay where they are.

Ok, I've made those changes in the diagram

[balmas]

On my opinion, we should modify the UI Controller to be on the Presenter level, and the App Controller - on the Model level only.

Yes, I agree. I also think that there is some clarity needed around the roles of the App Controller, Vue Modules (Data and Support) and Queries. In my view, it's the detangling of those that is driving the need for refactoring.

[kirlat]

In my view, it's the detangling of those that is driving the need for refactoring.

I think the detanglement would be extremely beneficial. We kept data in "ad-hoc in-memory databases" of different varieties, if we can put it this way. Using a more standardized approach to storing and retrieving data as GraphQL would allow a clearer separation between the Data Model and the rest of the application. That would help us to fit components/modules into the MVP architecture better.

[irina060981]

While I am working on my alignment-editor structure I use the following principals:

• vue components + styles = View layer here I have only visual components, simple actions and updates, styles and references to controllers actions based on events
• controllers + utilites = Presenter Layer I create controller for each complex and expandable (in future) action, it could have different manipulations with various data model instances. If it needs actions only with one type of data - it has references to data actions inside data model. If it need complex action (for example - download, tokenize) - it would have its own methods for them Also I have utilities - they contain complex logic for some specific actions inside controllers. For example, we could have several variants how to download, upload, tokenize data. Each variant would have its own utility class. Only controllers work with utilities. Also I have L10n module, from my point of view it is a utility/service by its sence. And may be it is better to attach it to the controller, and pass a ref to each visula component. But it is an overall utility - it is used inside all parts for having translation for labels and errors, so it is everywhere connected directly like a controller.
• data - Model Layer It contains each data class and actions inside it. As we have no only in-memory storage - it has also store here inside current instances of data