[Mvux][DesignPattern] How to apply the Repository Pattern in a Mvux uno application with DI?

[DevTKSS]

What would you like clarification on

Through the mvux is already seperating the VM tasks and data and in the existing Tutorials like for Feeds and States there are Services used to provide data operations, but thats actually making it harder to understand the actual seperation and architectural setup in case of a repository pattern would be wanted to be used.

I could imagine those two options of correct explanation to this but not be able to tell which is the correct one:

1. View-ReactiveVM-Model-Service-Repository-DataSource

2. Services are equal to Repository in Mvux (???)

Please add this explanation of usage for this DesignPattern differences to the docs and include sample code.
Thanks on advance!

Concern?

• Usage in industry
• Clarification of capabilities
• Getting started with Uno
• Developing with Uno
• Contributing to the Uno project
• Publishing your application
• Support
• Other (please specify):

For which Platform

• iOS
• macOS (AppKit)
• Mac Catalyst
• Android
• WebAssembly
• Windows
• Skia (WPF)
• Skia (GTK on Linux/macOS/Windows)
• Skia (Linux Framebuffer)
• Build tasks

Anything else we need to know?

To me the Services in mvux samples are looking same to repository tasks and also there is not always clear which business logic should be set to the model and which to the actual service.

Edited and added Information from here

Some Background Information and usecase I am considering this to be applyable

My question is not directly limited to mvux, but related and also to DI and will include a library project for example to be able to reuse this Repository Pattern designed Services with DRY Code pattern best practice. Appart from the web references for Repository Pattern, my usecase is not http but connecting to an other Desktop app thats having a api just like you would have a Api in web, only without the http stuff ;)

Note

The Class, which is wanted to perform this CRUD Operation is currently named "Service", but from the Tasks a Repository seems to do, it might be actually a Repository. Just for this explaination, I will just call it "Service". Its definition is placed already in a Library Project, so this would be able to reuse for other applications as is for me (not public awailable)

Planned Setup and Usecase:

1. Setup::

• Uno Single Head App
  • Target: Desktop
  • Preset: Recommended
  • Features:
    • DI
    • Configuration for NamedService and general data from appsettings
    • MVUX
    • uno.Navigation (simplyify the navigation and centralizing it)

2. Actions

• The Model was told to execute the function ReadParameters(Dictionary<string, decimal> iParameter) for a specific Document in that other app.
• Before it can do this, the required file & application to interact with, has to be connected
• From a ServiceProviderExtension I did create, it possible to get a (Singleton) ApplicationService and a DocumentService (<= named Service per file!) from the DI container. (Thinking of it might make sense to tell the ServiceProvider to already perform the connect app for me, but that could be against SingleResponsibility Pattern ?)
• So in case that has not been injected to the models constructor, the Task does now call:

if(IMyServiceProvider.GetApplicationService() is Other.Application app && 
   app != null &&
   IServiceProvider.GetDocumentService(NameOfService) is DocumentService docService && docService != null)
{
    if(docService.Connect(visible: true, openFileDialogOnFail: true) == true)
    {
       Dictionary<string,decimal> iParameter = await MyListState; // <= here we have one of the problems I am facing with mvux, seems to me no Dictionary type is possible with this and bind selectivly the ui to where needed, opened #2709 for this
       await MyListState.UpdateAsync(docService.ReadParameters(iParameter));
    }
}

• Description of ReadParameters:
  1. Check if its file & application is connected, ArgumentNullException.ThrowIfNull();
  2. Iterates with a for loop through a IEnumerable<Parameter> in this File/Document it has been connected to before, providing a INotifyPropertyChanged to the maybe listening to support a progressstate supporting control
  3. In case iParameter does contain the name of a Parameter in this iteration, it will grab its value and update the value in the Dictionary to it.
  4. After finishing this, the iParameter Dictionary will be updated with the current values

Same Operation other way around for WriteParameters, so in my opinion thats a classical CRUD case isn't it?

The Repository Pattern in general wants us to seperate the CRUD operations from the general business logic.
But although I did read and train my uno skills with the documentation to this, but I did not get:

• In General:
  • How to decide from which point, the logic would be recommended to be seperated to services
  • Which extend is okay to be placed at the model?
• On which place of this chain does then come the Repository?
• How will this be best set up?

The keypoint of this general question is, in mvux, there is already this/a seperation of interests coming from mvux and the business logic is placed at the model, while the Reactive vm is only told to take care of the view to model connection, ensuring the immutability.