framework MVC che utilizza le classi anziché i metodi per le azioni

Per chiarire, ciò di cui stai parlando con "esprimere i metodi attraverso le classi" è incarnato nel Pattern di comando ( link ).

Molte implementazioni del pattern MVC usano il Command Pattern per rendere il controller meno monolitico. Un esempio per un'implementazione in Java è avant ( link ).

Bene, dal punto di vista OOP, ci sono molti professionisti:

1. Le classi monolitiche (molte responsabilità) violano il principio di Separazione dei dubbi e la relativa manutenibilità della qualità
2. Usando il Command Pattern e la sua interfaccia, è facile estendere il tuo controller con nuovi comandi
3. Se desideri implementare qualcosa come un'operazione di annullamento , puoi farlo facilmente con lo schema di comando
4. Incarnare metodi per oggetti gettare le basi per il disaccoppiamento , dal momento che puoi passare gli oggetti del comando in giro e invocarli nella posizione appropriata nel tuo programma

Tuttavia esiste una piccola truffa:

• I pro non vengono per niente: devi scrivere una classe per ogni singolo metodo, questo è un po 'di overhead e potrebbe offuscare la grande immagine dell'applicazione in enormi applicazioni

Dato che sei interessato a "... un tipo di discussione che discute i pro ei contro di entrambi gli approcci " ecco i miei contro:

Se hai domainlogic nel tuo controller ( Antipattern Fat Controller )
quindi puoi risolvere il problema

• refactoring del controller di grasso in classi di grasso separate con il proprio dominio logico o
• refactoring del domainlogic dal controller del grasso in modelli grassi e / o grassi e crea un controller sottile.

Molti sviluppatori preferiscono avere Controller MVC sottili .

Se hai già un controller sottile, la classe di azione proposta sarebbe troppo piccola.