What we have:

The project is a WPF application that interacts with the site , a local database and displays data in the user interface.

Work example:

The site has something like topics that are updated from time to time. It is necessary to “download” the last state of these topics and write to the local database, let's call it synchronization. After synchronization, we can perform a quick search in the database, make various notes, add to favorites, etc., interacting through the user interface.

Vision structure:

The model turns out to be one, that for the base, that for MVVM. However, I also want to create an API layer that will interact with the site and return model instances. But then the API will need a model.

The result is 2 layers (or 3?) - API and DB (+ MVVM). Work with one model. So you need to use the Anemic model? Or is it better to separate the models, make your own layer for each layer?

Now about the logic of interaction with VM. If the user wants to get topics according to the criteria, the VM should start the synchronizer, wait for completion and only after that make requests to the database. Will the synchronizers (parsers), which through the API will receive topics and update them in the database, be allocated to separate classes or provide this VM-mom logic correctly?

enter image description here

What happened:

  • API layer interacting with the site
  • DB layer
  • Synchronizers linking API and DB
  • VMs interacting with the database and API via synchronizers
  • General DTO Anemic model for API, DB and MVVM.

Is it correct to use data separation and the approach to design in general?

    1 answer 1

    A terrible stream of consciousness that is difficult to understand.

    You essentially have a desktop client application to some site that allows you to take data from the site, view it offline and add some meta-information. So here are my markers ...

    I prefer an approach where there are models (entities) and services that can do something with these entities, that is, anemic.

    Models (entities) Do not produce dto unnecessarily. So the model (entity) "topic" will be the same for the database and for the client of the site and for viewmodeli until it is needed otherwise.

    The data access layer - everything depends on it. I prefer to treat it as external storage. And this means that there is a semblance of Repository / Storage, from which you can get data or put. He has to accept entities at his outer level and keep inside himself as he pleases. For example, be divided into 2 layers - the top layer works with entities, and the bottom one with simple types.

    There are many options for implementation and it depends on whether the model anemic. I do not welcome the rich model, which knows how to store itself, but a model that is degenerate in dto is also bad, so my models contain both data and some methods that make it difficult to save directly and inode force to use dto (but in practice I have from dto more problems than from pure anemic)

    The client to the site is a wrapper module. In the simple case, these are classes 1-2, which hide network requests and their data transmission in essence. Entering your own data types on the border of the module (and it is possible to write an additional adapter / mapping) makes sense only if this module is reused in other projects or you really want more isolation of the modules or we have an ORM that greatly hinders. Otherwise, we break YAGNI

    View (WPF + MVVM) - WPF displays, and MVVM provides the data to display and associates the view with the model. MVVM provides data for display and runs into the model for data or asking to do some work, but does not contain the application logic itself. Its business to connect a type and logic of the application. Although even with this, view models are bold, so some add controllers (MVVMC) to view models, which also take over the communication with the model.

    Synchronization is a service that relates to a model (not to be confused with entities), and not to a form, therefore, it does not exist as part of the view models.

    So we got the conditional modules. It all works together like this:

    • User clicks sync
    • WPF button zabindena team vuemodeli and this command works
    • The model viewer directly or indirectly accesses the synchronization service and asks for "synchronize." The viewmode itself does nothing more.
    • The synchronization service using the client to the site receives data in the form of entities and transmits it to the database layer for storage.
    • the view model either waits for the end of synchronization or uses events.
    • Viewmodel displays data (climbs behind them in for example)
    • The same entities are used for display, well, except that they turn into view models (good habit).

    There are still additional data that is not on the site - notes, the label "favorites" and so on. They can be stored separately from the "topic" entity, or you can as part of this entity (the client to the site simply does not affect those fields that he does not know). Decomposition is too controversial - I don’t like a lot of columns in the database, but the preservation and subtraction of the graph is also lazy to write.

    Introduction DTO - only when necessary. DTOs or entities of a particular module (or using simple types) allow us to achieve greater isolation of the module ... but YAGNI needs to think "should we need it?"

    Try to mark the boundaries of the modules to work only with them. In this case, the insides of the module are hidden. Even if you need some kind of interior, then try to provide access through the facade (module border)