search

alpheios-project / documentation

Alpheios Developer Documentation
0 stars 0 forks source link

Model-View-Presenter diagram of an app #39

Open kirlat opened 3 years ago

kirlat commented 3 years ago

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)

architecture_3_3_0

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 commented 3 years ago

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 commented 3 years ago

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

architecture_3_3_0(1)

balmas commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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