Il controller MVC è un controller caso d'uso?

Question

Il controller MVC è un controller caso d'uso?

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

1

In GRASP ( link ), un controller (use case controller) è definito come:

A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have a single UserController, instead of two separate use case controllers)

Riesco a vedere alcune somiglianze tra questo e il controller MVC. Tuttavia, non vedo una linea guida standard su come progettare un controller MVC. La maggior parte delle volte le persone dicono che dipende dallo sviluppatore e dal design dell'applicazione. Quindi mi chiedo se posso usare le linee guida sopra per progettare il controller MVC?

Per essere più specifici, supponiamo che un'applicazione abbia una pagina per visualizzare un elenco di prodotti in una tabella. Ogni prodotto viene visualizzato come una riga. Ogni riga ha un pulsante per ripristinare il prodotto (o qualsiasi altra operazione commerciale che abbia senso). Quindi, come vedo, questa pagina ha 2 casi d'uso (2 operazioni commerciali): elencare i prodotti e rifornire il prodotto.

Dalle linee guida di cui sopra, probabilmente avrò 2 case case controller per 2 casi d'uso. Quelli sono mappati a 2 controller MVC? O hai solo bisogno di un controller di prodotto con 2 azioni per 2 casi d'uso?

Se hai solo bisogno di un controller del prodotto, che ne dici di una pagina che ha molte operazioni commerciali nella stessa pagina? Presto il controller diventerà troppo grande. Naturalmente se una pagina ha troppe operazioni, potrebbe non essere una buona progettazione dell'interfaccia utente, ma a volte gli sviluppatori non hanno scelta perché i clienti vogliono che sia così conveniente

object-oriented design-patterns mvc use-case

posta Phuong Nguyen 30.04.2015 - 04:14

fonte

2 risposte

0

Nel pattern MVC, un controller media tra la vista e il modello. I metodi di azione in un controller dovrebbero essere sottili e non dovrebbero avere logica incorporata in essi. In GRASP puoi cercare il pattern di Indirection ( link )

Quindi quanti controller dovremmo creare o quanti metodi di azione dovrebbero essere in un controller, la regola generale è quella di raggruppare i metodi di azione correlati in un controller in modo che risultino puliti e ben organizzati.

Per il tuo caso, penso che sarebbe meglio creare un controller con meno di due metodi di azione, poiché sono molto correlati tra loro. Tuttavia, la logica per ReStock non deve necessariamente essere nel controller stesso.

List
rifornire

risposta data 30.04.2015 - 09:23

fonte

Leggi altre domande sui tag object-oriented design-patterns mvc use-case

Il modo migliore per segnalare a tutti i processi figli di terminare usando C Perché l'algoritmo di evasione della cache del piano di query EF riduce la cache alla dimensione del trigger di pulizia, causando una pulizia perpetua?

score 0 · Accepted Answer

Hai citato l'articolo di Wikipedia fuori dal contesto. In realtà dice:

The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event.

A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have a single UserController, instead of two separate use case controllers).

Quindi un controller caso d'uso è un tipo specifico di controller. Non significa necessariamente che questo è il modo in cui organizzerai i tuoi controllori, ma solo che è un modo di organizzarli.

I controllori possono essere organizzati in base alla responsabilità funzionale, al dipartimento o qualunque modello organizzativo abbia più senso per le tue esigenze particolari. Non esiste un modo "standard" per farlo.