Architettura del modello di vista

Question

Architettura del modello di vista

#1 da (2 voti)

3

Ho due schermi:

Una schermata con un elenco di elementi, in cui ogni elemento dell'elenco ha "Mostra dettagli" e "Aggiorna pulsanti"
Una schermata dei dettagli dell'elemento. Il pulsante "Mostra dettagli" passa alla schermata dei dettagli delle voci.

Quando fai clic sul pulsante "Aggiorna", è necessario prendere una decisione in base allo stato dell'articolo e quindi passare alla schermata di aggiornamento delle voci o chiedere conferma all'utente prima di procedere.

La schermata dei dettagli dell'elemento ha lo stesso pulsante "Aggiorna" che ha la stessa logica .

Ilproblemachehoècomeimplementareimodellidivisualizzazioneinmodopulitoinmodotalechelalogicadiaggiornamentononsiaduplicata.

Inprimoluogo,hocreatoimodellidivisualizzazioneperglischermi:

classItemListViewModel{publicObservableCollection<ItemViewModel>Items{get;}}classItemDetailsViewModel{//HowdoesthiscallsItemViewModel:UpdateCommand?publicICommandUpdateCommand{get;}}classItemViewModel{publicICommandShowDetailsCommand{get;}publicICommandUpdateCommand{get;}}

Percondividerel'UpdateCommand,vedoleseguentiopzioni:

ChiediaItemDetailsViewModeldicreareeconservareun'istanzadiItemViewModel:

classItemDetailsViewModel{ItemViewModel_itemViewModel;publicICommandUpdateCommand=>_itemViewModel.UpdateCommand;}

HaveItemDetailsViewModelderivadaItemViewModel:
```
classItemDetailsViewModel:ItemViewModel{}
```
UtilizzaunserviziocheimplementalalogicadiaggiornamentoechiamasiaItemViewModelcheItemDetailsViewModel
```
interfaceIItemService{voidUpdate();}
```

Sinotichepartedellalogicadiaggiornamentoèlanavigazione.HounIINavigationServicechevieneiniettatoneimodellidivisualizzazione.DovreipassareaIItemServicesescelgodiusarlo.

Nonsoqualesiailmiglioreeperché.Eccoalcunedellepreoccupazionicheho:

Opzionen.2:sembrastranoderivaredaItemViewModel.
Opzionin.3:l'utilizzodelservizioIItemsServicesembrainteressante,macomedifferenziarequestoserviziodaunaltroserviziochestaeffettivamentesalvandonellamemoria?Guardailservizioeilsuometodo"Aggiorna" non lo penseresti solo per la logica di navigazione.

Apprezzerei un consiglio e un ragionamento.

Gli articoli \ libri che ho trovato su MVVM sono troppo semplici e non parlano di scenari più complicati.

architecture design-patterns mvvm

posta Daniel 11.08.2018 - 08:48

fonte

1 risposta

Leggi altre domande sui tag architecture design-patterns mvvm

Che cosa è considerato buono / migliore pratica sulla gestione delle richieste di codifica ad-hoc? Approccio basato sul Domain Driven Design per il gioco

score 2 · Accepted Answer

Vorrei attenermi alla terza opzione.

Il primo non è ovvio e odora (imho), l'accoppiamento è sempre negativo. Inoltre, cosa succede se decidi di rimuovere il pulsante dalla classe "interna"? Spezzerà quello "esterno". L'accoppiamento dovrebbe essere evitato.

Il secondo è strano, l'ereditarietà dovrebbe essere usata per estendere alcune funzionalità, non per condividere del codice. Hai due schermi completamente diversi in modo che non abbiano una relazione genitore-figlio. E ancora, cosa succede se decidi di rimuovere la funzionalità dalla classe genitore e tenerla in child? Molto probabilmente trasferirai la tua implementazione in classe figlio, ma a quel punto l'ereditarietà non avrebbe assolutamente senso assolutamente . Se ti piace davvero l'idea dell'eredità, ti consiglio almeno di creare una terza classe, che sarà ereditata dai tuoi due.

L'unico problema con la terza opzione, come hai detto, è la denominazione. Ma questo è sempre un problema. Ti suggerisco di usare un nome come "ItemUpdateButtonProcessor", in questo modo non lo confonderai con l'azione di aggiornamento stessa (imho). Non ho familiarità con la lingua che usi, quindi forse ci sono alcune best practice sull'argomento, ma penso che tu abbia l'idea.