E 'anti-pattern per alterare il modello di dominio sul front-end?

Question

E 'anti-pattern per alterare il modello di dominio sul front-end?

#1 da (3 voti)
#2 da (0 voti)

3

Stiamo facendo un'applicazione per il quiz, sto cercando di integrare la mia interfaccia utente Angular 2 con l'API REST.

Il nostro modello di dominio Quiz è costituito dalla seguente gerarchia (semplificata):

-Quiz -Categoria -Domanda -Scelta

dove il genitore non conosce i suoi figli, ma il bambino conosce il genitore. Ad esempio, Choice ha un riferimento per una domanda, ma la domanda non ha alcun riferimento alla scelta. Abbiamo scelto questo approccio per essere in grado di recuperare i dati del questionario in modo più flessibile e modulare, evitando anche riferimenti circolari.

Tuttavia, nel front-end è contro-intuitivo usare il collegamento invertito, poiché le viste sono costruite naturalmente iterando strato per livello più in profondità nella struttura dell'oggetto dominio. È logico eseguire il rendering della vista per Domanda prima e visualizzare la sottoview per Scelte dopo. Sembra impossibile con il modello di dominio corrente, da dove dovrei partire da Choice.

La mia domanda è, se è comune o approvato convertire il modello di dominio sul front-end, quindi raccoglierò tutti i dati e aggiungerò il riferimento Choice a Question dopo, rendendo il modello compatibile per l'approccio top-down? E naturalmente riconvertirlo quando si esegue il POST a REST API.

Indica un design errato o è stato approvato per modificare il modello di dominio?

object-oriented design architecture design-patterns rest

posta Tuomas Toivonen 08.06.2016 - 19:32

fonte

2 risposte

Leggi altre domande sui tag object-oriented design architecture design-patterns rest

Gestione degli errori ed eccezioni in un'architettura a strati (o cipolla) [chiusa] Come viene chiamato il livello tra il controller MVC e il back-end?

score 3 · Answer 1

È molto tipico utilizzare il modello di dominio come risorse nel livello dell'API Web, ma di solito non è la cosa giusta da fare. Il livello dominio include client, inclusa l'API Web. L'API Web include client, inclusa l'interfaccia utente. Le esigenze e le esigenze dei client di dominio non sono le stesse delle esigenze e dei desideri dei client API Web.

Scrivi la tua API Web per i tuoi clienti. Se è meglio che i client abbiano un link da una risorsa di domanda alle risorse di scelta associate, quindi includi quel link. Se i clienti vogliono che le scelte siano incorporate, rendi questa un'opzione. Se ciò significa che il livello del dominio viene martellato perché è necessario effettuare più chiamate costose dal livello Web, quindi correggere il livello del dominio in modo che dia al livello Web quello di cui ha bisogno.

score 0 · Answer 2

È comune "invertire" i modelli front-end quando l'API è progettata per essere modulare in questo modo. Anche se questo è indipendentemente dallo stack tecnologico. Sia asp.net mvc, php o angolare, il tuo sito Web recupera la parte superiore verso il basso in modo da eseguire un'inversione esplicita o meno.

Il motivo per cui l'inversione è così visibile in Angolare è perché Angular è un framework di componenti nidificati. E i componenti nidificati richiedono che le gerarchie degli oggetti profondi rimangano intatte (quindi l'esplicito inversione). Questo è contrario a dire asp.net mvc, in cui il framework non si presta a componenti nidificati profondi, quindi gli sviluppatori tendono a suddividere i livelli della gerarchia degli oggetti in pagine separate con controller separati o ad appiattire la gerarchia in singoli modelli da visualizzato in singole viste con singoli controller che orchestrano le chiamate API. Quindi l'effetto "invertente" non è esplicito.

Quindi sì, è necessario invertire ed è accettato.

Il rovescio della medaglia su questo è costruire il tuo dominio in un approccio dall'alto verso il basso e la tua API in un approccio aggregato dall'alto verso il basso, che impedisce l'inversione sul client, ed è incredibilmente potente / conveniente con angolare. Dovresti quindi eseguire l'inversione nel tuo livello di accesso ai dati, che trovo molto meno dirompente.