L'uso tradizionale del controller in MVC porta a una violazione del Principio di Responsabilità Unica?

Question

Wikipedia descrive l'Single Responsibility Principle in questo modo:

La Responsabilità unico principio stabilisce che ogni oggetto deve avere un unico responsabile, e che la responsabilità debba essere interamente incapsulati dalla classe. Tutti i suoi servizi dovrebbero essere strettamente allineati a tale responsabilità.

L'uso tradizionale del controller in MVC sembra condurre un programmatore verso una violazione di questo principio. Prendi un semplice controllore del libro degli ospiti e guarda. Il controller potrebbe avere due metodi/azioni: 1) Indice() e 2) Invia(). L'indice() visualizza il modulo. Submit() lo elabora. Questi due metodi rappresentano due distinte responsabilità? In tal caso, come entra in gioco la Responsabilità Unica?

Answer 1

Sì, sì.

E se si desidera seguire l'SRP, si disaggrega il controller in un Dispatcher e azioni; il Dispatcher invia il controllo alle sue azioni e in fase di compilazione (modelli C++) o in fase di esecuzione (Java XML, qualunque sia), comporrà Dispatcher e Azioni.

Perché non lo vediamo più spesso? Perché i Controller sono spesso implementazioni "ad hoc", classi concrete a livello di foglia che non sono generalizzate e non intendono essere sottoclassate. Qui, la classe è usata più per raggruppare comodamente il codice, le azioni sono quasi certamente non pubbliche (probabilmente private, forse protette), "semplicemente" dettagli di implementazione interna.

La scelta di come decidere quale azione inviare, il numero e la diversità delle azioni possibili, è elevata e il dispacciamento e l'azione sono strettamente accoppiati. Quindi, in pratica, è spesso più semplice mettere insieme il codice in un unico posto.

Answer 2

No, non è così.

Non c'è nulla di intrinseco al pattern MVC o alle sue variazioni che portano a una violazione del Principio di Responsabilità Unica. Se l'implementazione di un controller viola o meno l'SRP si basa sul fatto che il comportamento incapsulato abbia più di una ragione per cambiare (proprio come qualsiasi altra classe), non a causa di un presunto uso prescrittivo del modello.

L'esempio che viene presentato è un sottoinsieme di moduli di base sull'applicazione dati, in cui il controller sta semplicemente fornendo operazioni CRUD per un determinato modello. Le operazioni di CRUD sono di natura abbastanza coesa, quindi questo generalmente non costituisce una violazione di SRP. Dove avere più metodi su un singolo controllore iniziano a diventare sospetti è quando i metodi rappresentano diverse interazioni comportamentali attraverso il dominio.

Detto questo, anche se qualcuno su cui argomentare che CRUD rappresenta quattro distinte preoccupazioni non coesive, non c'è nulla di intrinseco al modello MVC che ti costringa a facilitare ciascuna di queste azioni all'interno dello stesso controller.

Per un po 'di storia sul pattern MVC e qualche discussione sulla sua applicazione nello sviluppo Web, checkout Interactive Application Architecture Patterns.