Perché i framework danno maggiore flessibilità ai modelli rispetto ai controller?

Question

Perché i framework danno maggiore flessibilità ai modelli rispetto ai controller?

#1 da (7 voti)
#2 da (5 voti)

1

Ho sempre cercato di mantenere i modelli solo per l'interazione diretta con il database e mantenere tutta la logica effettiva nei controller. Di solito, un framework o una piattaforma fornisce maggiore flessibilità ai modelli e limita la libertà dei controllori.

I modelli di solito sono in grado di essere richiamati da più controller.
I modelli di solito sono in grado di essere richiamati da altri modelli.
Nel caso di Magento, i CRON non possono essere richiamati sui controller.

A volte sembra che i framework vogliano che i controller siano un router avanzato. A volte finisco per mettere la logica non di database in Modelli, o usare concetti come Helpers o un concetto specifico per il framework, nessuno dei quali non mi piace fare.

Qual è il vantaggio di non dare ai controllori la stessa libertà che i modelli ottengono in genere? Devo guardare MVC in modo diverso da come sono?

architecture design-patterns frameworks mvc

posta Goose 04.08.2017 - 16:49

fonte

2 risposte

5

Perché la logica aziendale non è una delle responsabilità dei controllori e MVC si basa sulla separazione delle preoccupazioni.

Non stai guardando in questo modo. L'obiettivo principale di MVC è fornire un meccanismo per la gestione dell'interfaccia utente separatamente dal modello. Rimandando tutti gli altri dubbi al modello, MVC ti consente di progettare il tuo modello in totale libertà modo che desideri.

risposta data 04.08.2017 - 16:57

fonte

Leggi altre domande sui tag architecture design-patterns frameworks mvc

C'è un buon delimitatore a byte singolo da usare con le stringhe utf-8 che non è un terminatore nullo? Questo algoritmo ha un nome?

score 7 · Accepted Answer

"Modello" in questo contesto (e nel contesto di MVC, MVP, MVVM, ecc.) è non qualcosa che usi per l'accesso al database. È non un modello di dati. Inoltre non si riferisce ai "modelli di vista" che si possono trovare in alcuni framework (quelli fanno parte del livello di presentazione).
È un insieme di componenti software (qualunque essi siano) che modelli il tuo dominio (cioè una rappresentazione software di aspetti rilevanti del dominio del mondo reale).

Ciò significa che è il modello che implementa effettivamente il comportamento di base del sistema. È nel modello in cui risiede l'effettivo funzionamento delle ossa nude del sistema (e quindi ci si aspetterebbe che contenga logica non DB). Tutto il resto, incluse le visualizzazioni, i controller e persino l'accesso al database, è qualcosa che "si collega" al Modello. La direzione delle dipendenze dovrebbe essere verso il modello. Fondamentalmente, nell'architettura a strati, il modello fa parte del livello di business logic (BLL), o nei sistemi più semplici, è il BLL.

Il compito del Controller è capire come coinvolgere il Modello in base all'input dell'utente e tradurre i dati provenienti dalle Visualizzazioni in un formato più adatto al Modello.

Dall'altro lato del BLL si ha accesso al DB attraverso un componente (Gateway, Repository) che incapsula l'accesso ai dati e, se necessario, traduce i dati dal formato trasmesso dal BLL, in un formato previsto dal DB ( o un ORM). Dipende anche dalla BLL (inversione di dipendenza).