Visualizzazione dei dati personalizzati nel livello di presentazione

4

Ho un paio di modelli Merchant e Offer . Un commerciante può avere più offerte. Sto sviluppando un'applicazione web e scrivendo un componente personalizzato che mostra i dettagli dell'offerta come title , description ecc. Devo anche mostrare la miniatura del commerciante nello stesso componente.

I dati che ho sono elenchi di offerte in JSON e ogni offerta contiene merchant_id . Quello che sto mostrando al momento è per mostrare ogni carta offerta che sto recuperando il suo dettaglio mercantile associato e poi passando due modelli nel mio componente presentatore vale a dire offer e merchant , sono sicuro che in futuro avrò bisogno di più informazioni da mercante.

È una buona pratica o dovrei passare un modello personalizzato che contiene sia i dettagli del venditore che dell'offerta e il nome è qualcosa come OfferDescription e per salvare richieste extra prepopolare questo modello dal back-end?

Non sono sicuro che ci sia un approccio migliore. Il mio criterio principale è la flessibilità e la manutenibilità.

    
posta CodeYogi 08.06.2017 - 10:04
fonte

2 risposte

4

Un livello di presentazione non ha l'obbligo di utilizzare le stesse astrazioni del modello che usa. In effetti c'è molto potere nell'usare astrazioni diverse.

Sembra che l'astrazione di cui hai bisogno nella tua presentazione sia "carta offerta" e non sia la stessa offerta o mercante. Consenti a questa differenza di essere riflessa nel codice. Non creare un oggetto modello "carta offerta". Avere un oggetto di presentazione "scheda offerta" che accetta i messaggi dagli oggetti del modello. Può quindi popolare un'interfaccia utente con tali informazioni.

Andare dall'altra parte può funzionare, naturalmente. Ma in realtà ha esattamente lo stesso problema ereditario. Certo, ottieni un nuovo livello e qualche riferimento indiretto, ma l'interfaccia è la stessa, quindi il livello di astrazione è lo stesso. Questo è molto limitante. Preferisci le nuove astrazioni nei nuovi livelli alle vecchie astrazioni.

Can you please elaborate on " Have an "offer card" presentation object that takes messages from the model objects."? - CodeYogi

Certo. In questo diagramma il tuo modello ora è Business Rules.

Eccounesempioincuiiltuopresentatoredella"scheda offerta" non conosce o conserva un riferimento alla tua offerta o ai modelli di commercianti. Tutto ciò che il tuo relatore deve fare è implementare le interfacce con cui parlano. Quando parlano con te traduci ciò che dicono in cose che l'interfaccia utente può visualizzare.

Come relatore, non fai nessuna domanda al modello. Non chiedi all'interfaccia utente domande. Ti viene detto di fare cose e dici ad altre cose di fare cose.

Questo è segnala, non chiedere . Assicura che mentre attraversi un livello hai tutti i benefici del polimorfismo, di essere orientato agli oggetti e avere il diritto di astrarre comunque ti senti come se stessi astrattamente.

È incredibilmente potente. Ma per trarne il massimo vantaggio è necessario essere disposti ad astrarre a ogni livello. Questo significa pensare a molti nomi. Per fortuna, hai già fatto il duro lavoro: "Offerta carta". In effetti, dal momento che ho imparato a strutturare il mio codice in qualsiasi modo immaginabile, sono arrivato a scoprire cosa mi limita più di ogni altra cosa è pensare a un buon nome.

Se ti stai chiedendo esattamente cosa significa "parlare", ecco come lo dice lo zio Bob:

You separate the UI from the business rules by passing simple data structures between the two. You don’t let your controllers know anything about the business rules. Instead, the controllers unpack the HttpRequest object into a simple vanilla data structure, and then pass that data structure to an interactor object that implements the use case by invoking business objects. The interactor then gathers the response data into another vanilla data structure and passes it back to the UI. The views do not know about the business objects. They just look in that data structure and present the response.

Robert C Martin

Per dirla in modo un po 'più semplice

The important thing is that isolated, simple, data structures are passed across the boundaries. We don’t want to cheat and pass Entities or Database rows. We don’t want the data structures to have any kind of dependency that violates The Dependency Rule.

Robert C Martin

Una buona risposta esistente al riguardo è fornita da @zapl

    
risposta data 08.06.2017 - 11:13
fonte
1

È possibile utilizzare due modelli nella vista, ma ciò significa che la vista dovrà contenere la logica per coordinare correttamente questi due modelli. Questo ha due inconvenienti:

  1. Le viste sono la parte più difficile del sito al test unitario. Quindi vorrai mantenere la logica il più semplice possibile.
  2. Se vuoi mostrare la scheda offerta in una vista diversa, dovrai implementare nuovamente la logica nella seconda vista.

Raccomando di creare un modello che rappresenti la carta offerta in modo da poter mantenere la logica contenuta nel puro codice c # in cui è più facile testare e riutilizzare.

    
risposta data 08.06.2017 - 19:36
fonte