Principi MVC / MVVM

Question

Principi MVC / MVVM

#1 da (0 voti)

-1

Attualmente sto lavorando all'aggiornamento di alcuni vecchi progetti (cose ereditate) e continuo a correre su vari piccoli problemi con l'architettura. Ovvero classi monolitiche troppo strettamente accoppiate.

Un esempio al momento è un gigantesco oggetto "risultati" che assomiglia a:

public class Person 
{
   string Name;
   string Address;
   List<FavoriteThings> favorites;
}

public class FavoriteThings
{
  List<ARGBColor> Colors;
  List<Recipe> Food;
}

Alcuni di questi sono abbastanza profondi e alcune classi medio-grandi (20-50 oggetti)

La vista utilizza circa 15 campi in totale.

Quali principi descrivono meglio gli odori di codice che sto rilevando? SOLIDO? Ci sono dei veri motivi per avvicinarsi allo schema in questo modo? O è un anti-pattern? Voglio sapere se sto esaminando questo codice? O sono sul percorso di scrittura per voler estrarre / refactare questo significativamente a più di un patter MVVM con classi con informazioni minime esposte, se necessario.

design-patterns solid mvvm

posta AthomSfere 21.08.2018 - 23:27

fonte

1 risposta

Leggi altre domande sui tag design-patterns solid mvvm

Come testare funzionalità che crea solo input per una dipendenza da middleware di grandi dimensioni Con un'API Web, elenco di oggetti o dizionario con elenco?

score 0 · Answer 1

È meglio considerare sempre i principi SOLIDI. Perché rende il tuo codice più semplice e facile da mantenere.

Come ho capito, le classi Persona e FavoriteThing sono sia il dominio che le entità dati e sono anche esposte alla Presentazione. Penso che sia il primo odore di design qui. Abbiamo bisogno di oggetti diversi per rappresentare lo stesso concetto in diversi livelli. Queste classi sono progettate con tabelle e struttura dei dati in mente. Quindi potrebbero esserci già alcuni problemi tra i tuoi dati e i livelli del dominio. Voglio dire, forse quei 15 (più o meno) campi sono sufficienti per il dominio, ma altri campi ci vivono a causa di strutture di tabelle o problemi di dati!

Quindi il primo problema che abbiamo qui è il SOC. Queste classi sono classi di dominio e gestiscono la logica del dominio ma ViewModels sono classi di presentazione e gestiscono la logica di presentazione. Quindi ci sono diverse preoccupazioni qui. Separali! E inoltre succede più volte che ViewModels ha bisogno di più o meno dati che esistono in più oggetti di dominio. È davvero difficile riempire ViewModels con diversi tipi di oggetti di dominio. È possibile utilizzare ServiceLayer e DTO per questo problema. Un'altra cosa, non cambiare le tue entità di dominio a causa di ViewModels o qualsiasi altro oggetto di presentazione. Gli oggetti del dominio cambiano solo a causa delle esigenze aziendali.

Anche questo tipo di violazione viola l'OCP. Perché quando le tue classi hanno sempre più clienti avranno sempre più motivi per cambiare. E questo rende difficile prendere in considerazione l'OCP.

Quindi, prima di tutto, rispetta i principi e i codici separati che hanno preoccupazioni diverse. Quindi avvia il refactoring ovunque tu pensi che ne abbia bisogno! Ciò ti porta a considerare i problemi relativi ai domini quando esegui il refactoring degli oggetti del dominio e i problemi di presentazione durante il refactoring di ViewModels o altri oggetti di presentazione.