è una cattiva pratica che controllore chiama oggetti dominio (entità) direttamente anziché servizio?

Question

è una cattiva pratica che controllore chiama oggetti dominio (entità) direttamente anziché servizio?

Naviga le tue risposte

#1 da (4 voti)
#2 da (2 voti)

4

è una cattiva pratica che il controller chiami i metodi degli oggetti di dominio direttamente invece del servizio?

per saperne di più:

Capisco che nei buoni controllori di design i servizi di chiamata e servizio utilizzano oggetti Dominio (entità).

ma a volte nel controller non ho / ho bisogno di alcuna logica e ho solo bisogno di recuperare da db e passarlo a vista

e posso farlo semplicemente chiamando i metodi negli oggetti Dominio (entità) - non c'è bisogno di chiamare il servizio - è una cattiva pratica?

come esempio

Class Student{

public function getName(){//return the student name};
public function setName(){//setting the the student name};

}

accedi al metodo getName () direttamente dal controller

object-oriented design-patterns domain-objects mvc entity

posta Susantha7 19.02.2017 - 16:02

fonte

2 risposte

Leggi altre domande sui tag object-oriented design-patterns domain-objects mvc entity

Design pattern per alberi isomorfi Come dovrebbero essere mostrate le librerie nel diagramma delle classi UML?

score 4 · Answer 1

Architettura MVC originale

Nell'architettura MVC originale (Xerox PARC nel 1979), il controller gestisce l'interazione dell'utente. Interagisce con il modello e con una o più viste. La scissione della responsabilità richiede che il controllore non intervenga nel rendering che è di responsabilità della vista.

In questa architettura, non c'è bisogno di servizi: è perfettamente valido per un controller accedere direttamente agli oggetti del dominio.

Discendenti MVC

Questo è diverso da un'architettura MVP (inizialmente introdotta da Talligent nel 1996), in cui il presentatore (ovvero il controller) funge da intermediario tra la vista e il modello. L'idea è che in un'architettura client-server, il presentatore potrebbe essere diviso tra il server in cui viene mantenuto il modello di dominio e il client che si occupa della vista.

Ecco perché, in MVP, il controllore dovrebbe accedere al modello solo attraverso "comandi" e "selezioni". Quindi qui dovrebbe essere usato un livello di servizio.

Livello di servizio o no?

Questo articolo fa la differenza tra MVC, MVP e MVVM chiaro.

Sfortunatamente i framework hanno spesso una propria comprensione di MVC (ad es. Apple o team di Google Chrome ). Non è chiaro quale framework MVC stai usando: se necessario modifica la tua domanda per chiarire.

Tuttavia, indipendentemente da MVC, un dominio potrebbe essere utilizzato da diverse applicazioni tramite un'API (o implementato come microservizio). Quindi un livello di servizio potrebbe essere richiesto a causa di altre considerazioni di architettura e non a causa di MVC.

score 2 · Answer 2

Penso che @Christophe fornisca una risposta eccellente per quanto riguarda l'approccio ai servizi nei pattern MV *, aggiungerò una risposta nel caso in cui la tua domanda riguardasse il Domain Driven Design.

In un approccio DDD, la risposta alla tua domanda è più chiaramente "No, non è sbagliato". In genere, avvii la progettazione utilizzando solo modelli di dominio, interagendo direttamente con loro e chiamando direttamente i loro metodi. Quando si ha bisogno di tali servizi, si tiene conto dei servizi solo perché è necessario coordinare un comportamento che esula dall'ambito di una singola entità o che si interfaccia con una preoccupazione esterna all'applicazione (ad esempio, database o servizio Web).