Ho bisogno di spiegare MVC ai non programmatori. Vale a dire, ai dirigenti di altri dipartimenti, nel contesto della relazione sullo stato di avanzamento. Una delle cose che faccio è rielaborare la nostra base di codice verso la separazione MVC.

Qual è la separazione MVC che potrebbero chiedere? Perché è necessario che potrebbero chiedere?

Dopo aver letto una risposta abbastanza tecnica come questa: che cos'è davvero MVC? , Non sono del tutto soddisfatto, poiché parlerò con i non programmatori. Potrebbero annuire, ma probabilmente non capiranno di cosa si tratta e perché sia ​​necessario.

In realtà, non afferro completamente ciò che MVC è diverso da "separazione di preoccupazioni, doveri, funzioni, classi, blocchi, compiti, cose, al fine di migliorare la flessibilità di apportare modifiche al software". Separare il database dalla vista e dalla logica aziendale usando tecniche come strumenti e tecniche DI e OO è qualcosa che considero essere la separazione MVC.

Quindi la prossima volta che spiegherai MVC a un non programmatore che ha un background nelle vendite e nella contabilità, ad esempio, cosa diresti loro?

Non spieghi MVC.

Quello che fai è spiegare che si tratta di una ristrutturazione della base di codice.

Una ristrutturazione che semplifica la base di codice e quindi consente agli sviluppatori di apportare modifiche più rapide e migliori alle segnalazioni di bug e alle richieste di funzionalità, con meno bug.

Non hanno bisogno di conoscere i dettagli tecnici, solo il motivo per cui è stato fatto, cosa è stato ottenuto facendo ciò e quali vantaggi per l'azienda.

In altre parole, parla loro la loro lingua.

Mentre sostengo il senso della risposta di Oded , che dovresti spiegare i progetti tecnici ai dirigenti delle imprese nella loro "lingua", ho una scrupolosità su "non hanno bisogno di conoscere i dettagli tecnici, solo perché è stato fatto".

Se stai partecipando a un progetto o a una riunione di riesame degli investimenti con i capi dipartimento e dichiari "questo è quello che stiamo facendo", potrebbero voler chiedere "Umm ... perché? Sembra un grande investimento di tempo ed energia. Potresti darci un po 'più di comprensione di ciò che stai facendo e perché? " Sembra una domanda eminentemente ragionevole. Non vuoi essere sorpreso in una posizione di "Beh ... è complicato". o "No, non posso davvero spiegarlo." o "Non preoccuparti." Più è senior il personale per il quale stai esaminando il progetto, meno è probabile che lascino volare "sono solo cose che non riesco a spiegare bene". Meglio se riesci ad approfondire almeno un livello per far sentire gli altri a proprio agio che 1) sai cosa '

Quindi, hai uno schizzo di MVC nella tasca dei fianchi, pronto per partire. Qualcosa di simile a:

"È un po 'tecnico, ma ... MVC divide il codice in Modelli (responsabile dei dati di base e della logica aziendale), Viste (che visualizza i dati) e Controller (che gestiscono le interazioni e gli aggiornamenti degli utenti). È un'architettura collaudata- "probabilmente il modello di progettazione di maggior successo dell'ingegneria del software. So che potrebbe sembrare" solo un po 'di impianto idraulico ", ma per gestire tutte le richieste in arrivo, abbiamo bisogno di una base più solida. Questo ci metterà sulla base giusta per costruire nuovi funzioni e risoluzione più rapida dei bug ".

Anche se alla fine non capiscono completamente MVC, e anche se dovessi semplificare eccessivamente per renderlo comprensibile ("rompi alcune uova per fare una frittata"), scommetto che troverai molto più comodo avere una spiegazione pronta che dover dire "Non posso spiegarlo" o "non sei qualificato per capirlo" ai dirigenti.

al fine di migliorare la flessibilità di apportare modifiche al software

I manager sono interessati al risultato finale. Meno tecnici sono, meno è probabile che si preoccupino di come ci si arriva. MVC è molto comune, popolare e provato.

Quando le richieste di modifica verranno effettuate in futuro, è possibile far sapere al management che possono essere rese più facili e veloci. A tutti piace sentirlo.

È una strategia comune, quindi assumere nuovi sviluppatori non dovrebbe presentare un problema. In effetti, potresti attirare sviluppatori migliori che sono forti sostenitori.

Tutto ciò sarà molto difficile se ci sono molti problemi urgenti in questo particolare progetto. Potrebbero non essere disposti a fare un passo indietro in modo da poter fare due passi avanti. Sulla soluzione potrebbe essere aspettare o implementare in pezzi più piccoli.

• Modello - Fili / elettricità
• Visualizza - Lampada
• Controller - Interruttore luci

Componenti relativamente facili da sostituire (lampada, interruttore luce / dimmer). Forse non tanto il cablaggio, ma può ancora essere fatto senza influenzare altri componenti. Tutti dovrebbero essere in grado di visualizzarlo nella loro testa, anche i tipi di marketing / vendita. (Chiara separazione, ecc.)

Ora dite al vostro capo / colleghi che nella nostra applicazione / sistema l'interruttore è incorporato all'interno della lampada e la lampada è avvolta in filo di rame. Ora immagina di provare ad aggiornare la lampada, l'interruttore o il filo. Molto costoso, impatto su altri componenti molto elevato e forse pericoloso da fare senza rompere qualcos'altro.

MVC sta applicando un modello alla base di codice che trasforma il disordine confuso (ma funzionante) in qualcosa in cui i cambiamenti possono avvenire più velocemente e più facilmente con meno errori.

Un modo semplice per capire MVC: il modello sono i dati , la vista è la finestra sullo schermo e il controller è la colla tra i due .

La migliore rubrica di sempre: "Abbiamo bisogno di modelli SMART, controller THIN e viste DUMB"

Come con altri schemi di progettazione software, MVC esprime il " nocciolo della soluzione " a un problema, consentendo al contempo di adattarlo a ciascun sistema. È meglio visto come un concetto invece di un'implementazione specifica. Esistono molte implementazioni del concetto.

Tutte le varianti MVC utilizzano la stessa divisione di componenti, ma di solito differiscono nel modo in cui questi componenti interagiscono.

Per quelli di voi che non ne sono a conoscenza, MVC è stato originariamente descritto in termini di un modello di progettazione da utilizzare con Smalltalk da Trygve Reenskaug nel 1979 . Il suo articolo è stato pubblicato con il titolo "Programmazione di applicazioni in Smalltalk-80: come utilizzare Model-View-Controller" e ha gettato le basi per la maggior parte delle future implementazioni MVC.

Sono per metà d'accordo con Oded: imparare a convincere i tuoi colleghi e manager non tecnici che ciò che stai facendo è importante e utile, senza spiegare i dettagli grintosi, è un'abilità necessaria che saresti saggio sviluppare.

Tuttavia, credo che avere la capacità di spiegare concetti complessi in termini semplici aiuta in realtà a farlo - un problema che i manager non tecnici spesso hanno è che poiché hanno difficoltà a capire esattamente cosa stanno facendo i tecnici, hanno la tendenza a diffidare di loro. È solo la natura umana: è più facile credere che qualcosa che non capisci sia inutile o sbagliato piuttosto che fidarti di esso. Pertanto, se riesci a rendere i concetti facili da capire a piacimento, puoi usarli ogni volta che ne hai bisogno e, nel tempo, i tuoi manager non tecnici impareranno che possono capirlo se vogliono - non ne stai superando uno su di loro - stai solo risparmiando loro i dettagli per la loro sanità mentale. Si fideranno di più di te.

A parte questo, rispondiamo alla domanda:

Trovo utile usare analogie che gli uomini d'affari comprendono. Per MVC, lo descrivo come un business.

• I modelli sono responsabili della logica e dei dati aziendali: sono le cose che definiscono cosa fa il programma e i dettagli di come lo fa. Se il programma fosse un business, i modelli sarebbero i magazzini, le fabbriche, i lavoratori e le attrezzature di capitale. Sarebbero anche i dirigenti di livello inferiore che si assicureranno che le regole vengano seguite e che la politica venga applicata.
• Le viste sono il livello di presentazione: mostrano agli utenti cosa sta succedendo nel sistema e forniscono un mezzo per interagire con il programma. Se il nostro programma fosse una società, le opinioni sarebbero come il pavimento dello showroom, lo stand di vendita alla convention commerciale o i rappresentanti di vendita. Visualizzano le opzioni, forniscono informazioni e feedback intuitivi e rispondono alle richieste dell'azienda.
• I controller sono il livello di coordinamento: assicurano che le informazioni arrivino dai modelli alle viste e viceversa e che tutto funzioni insieme per svolgere il proprio lavoro. Se il programma fosse una società, i responsabili del trattamento sarebbero i dirigenti di livello medio e alto. Non sono troppo coinvolti nei dettagli, ma si assicurano che le persone giuste abbiano gli strumenti giusti per fare il loro lavoro e approvano o negano decisioni di alto livello. Forniscono la direzione generale in modo che le cose possano lavorare insieme.

Il vantaggio di spiegarlo con questa analogia è che un buon manager vedrà la saggezza nel separare le preoccupazioni in questo modo e potrebbe decidere che dovrebbero essere più simili ai controller e non essere troppo coinvolti nei dettagli in futuro!

Che si spera possa rispondere al "cosa" - il "perché" è anche facile con questa analogia:

Immagina un'azienda ideale, in cui ogni dipartimento è responsabile di una serie di attività e sa che avrà sempre le risorse di cui ha bisogno senza doversi preoccupare di ciò che fanno gli altri. Un rappresentante di vendita trova un cliente, ottiene il suo ordine, lo restituisce alla direzione che lo approva e quindi va al magazzino / produzione / ingegneria per l'evasione. Il feedback è diretto - nessun altro deve essere coinvolto a meno che non ci sia un problema. È un buon design MVC: ogni parte ha un lavoro e non deve preoccuparsi di altre parti. In questo modo, è facile cambiare se necessario. In un progetto non MVC, le responsabilità non sono chiare. Il rappresentante di vendita può provare a modificare il prodotto quando il cliente richiede qualcosa di diverso. Oppure potrebbero dare prezzi diversi a seconda di come si sono sentiti quel giorno. L'amministratore delegato potrebbe essere a terra in disordine con la linea di produzione, quando dovrebbe essere preoccupato di come mettere in atto una catena di approvvigionamento più affidabile. Gli addetti al magazzino potrebbero essere fuori dal reparto vendite a parlare con i clienti quando dovrebbero soddisfare gli ordini già presi.

In altre parole, un buon design MVC consente a ciascuna parte di concentrarsi su una cosa, in modo che possa farlo nel modo giusto, proprio come un'azienda ben organizzata.

** Dichiarazione di non responsabilità - se la tua azienda è mal organizzata, potrebbero esserne offesi. In tal caso, avrai bisogno di un'altra analogia. Potresti anche aver bisogno di un lavoro diverso.

I vantaggi di MVC sono principalmente nella separazione delle preoccupazioni:

Permette alle persone di concentrarsi su ciò che fanno meglio.

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

Riduce i costi perché i sistemi intrecciati richiedono che il personale sia esperto in tutte queste aree o che è più probabile che si verifichino problemi quando un cambiamento in un'area influisce sulle altre.

Fornisci esempi reali di architetture MVC: telefoni cellulari, telefoni desktop, Skype, ecc. La modifica della vista (tipo di tastiera, altoparlanti, microfoni) non influisce sul modello (il segnale audio), il controller è il circuito in il telefono che traduce le onde sonore in segnali audio.

Direi loro che MVC separa le mie preoccupazioni.

La mia prima preoccupazione è la logica del codice - cosa faccio dietro le quinte per fare in modo che il sito web esegua le azioni che vogliono.

La mia seconda preoccupazione è la logica aziendale: cosa vogliono (l'utente) dall'applicazione.

La mia terza preoccupazione è l'aspetto del sito: la pagina che visitano per fare ciò che vogliono.

(Non dirò loro questa parte successiva) Quindi, in ordine, le mie spiegazioni erano per il Modello, il Controller e la Vista.

Spiega i vantaggi

Spiegherei MVC in termini di vantaggi aziendali. I tuoi manager saranno in grado di capirlo e saliranno se i vantaggi sono convincenti.

MVC ti consente di suddividere l'applicazione in unità sensibili, ognuna delle quali esiste indipendentemente dalle altre. Ottieni codice pulito, gestibile, testabile e potenzialmente riutilizzo del codice tra i sistemi.

Il modello

Ogni modello incapsula un singolo tipo di informazioni aziendali, ad esempio un record cliente o un prodotto, insieme a tutte le logiche aziendali correlate.

La separazione di questo consente di testare facilmente la logica aziendale in modo isolato dalle altre parti dell'applicazione.

Puoi anche estendere facilmente l'applicazione aggiungendo ulteriori modelli, è molto modulare e pulito.

Ogni modello in teoria può esistere indipendentemente dagli altri. Si potrebbe prendere in considerazione la possibilità di applicarlo utilizzando gli oggetti di servizio per gestire le relazioni tra i modelli. È possibile sostituire i modelli senza influire sul resto del sistema.

La vista

Separare la visualizzazione consente di aggiornare facilmente il front-end senza interrompere il back-end sottostante.

Puoi fornire il tuo codice front-end a un altro sviluppatore senza necessariamente fornire loro l'accesso all'intero sistema.

Sei anche libero di creare front-end alternativi che funzionano con il sistema esistente. Potresti mostrare i tuoi dati come un'app mobile, un'API, un PDF o un foglio di calcolo Excel. Puoi farlo senza hackerare il resto del sistema. È meno probabile che rompa le cose accidentalmente. È possibile creare rapidamente punti di integrazione a cui agganciare i sistemi esistenti.

Il controller

Il controller collega i modelli alla vista. Mantiene tutto separato. È possibile cablare in una vista diversa molto facilmente. Se modifichi il codice del modello, la vista non ha nemmeno bisogno di sapere.

Altri vantaggi

È un modello comune. Altri sviluppatori saranno in grado di capire il tuo codice e lavorarci su. Se ritorni al tuo codice anni dopo, probabilmente sarai in grado di capirlo e apportare modifiche. Il tuo codice avrà meno probabilità di diventare un altro mal di testa legacy per un futuro sviluppatore.

Poiché tutto ha un posto, è molto più facile produrre codice pulito. Il rischio di spaghettificazione è drasticamente ridotto (anche se non eliminato). Il tuo codice diventa gestibile.

Poiché tutto è modulare, è possibile testarne parti separatamente. Il tuo codice è testabile e ha meno probabilità di ospitare bug o falle nella sicurezza. I futuri aggiornamenti saranno molto più semplici in quanto sarai in grado di testare facilmente l'intero sistema.