Questo costituirebbe MVC - anche in un senso molto sciolto?

Question

Questo costituirebbe MVC - anche in un senso molto sciolto?

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

6

Ho lavorato su una specie di CRM per i venditori nel nostro ufficio - non come un lavoro ma come un tipo di attività del tempo libero - non pretendo di essere uno sviluppatore o qualcosa del genere, ma mi piacerebbe sicuramente perseguire una carriera come sviluppatore web su tutta la linea, penso solo che ho bisogno di una comprensione molto più strong dei principi OOP e dei modelli di progettazione come MVC prima che potessi anche considerarlo.

Fondamentalmente il modo in cui l'ho sviluppato ogni sezione dell'App è una pagina html, che usa jQuery per ascoltare gli eventi, che poi invia richieste Ajax al server, che vengono poi reindirizzati ai metodi di classe che si esibiranno di solito semplici Compiti CRUD, e rimandare una risposta JSON al client che verrà poi riflessa sulla pagina - questo costituirebbe il mvc anche in senso ampio, in quanto la presentazione è completamente separata da cose come l'interazione con il database e c'è un intermediario tra l'interazione tra i due?

Come se dicessi che sono nelle primissime fasi della lotta alla comprensione di MVC nel suo insieme, quindi ogni pensiero sarebbe apprezzato, grazie.

mvc

posta Keir Lavelle 02.08.2012 - 19:15

fonte

3 risposte

Leggi altre domande sui tag mvc

Come mantenere la guida dell'utente in linea con le filiali per un non sviluppatore? Livello di Full Trust: dovrebbe essere una preoccupazione?

score 5 · Answer 1

Sicuramente sembra un buon progetto e non un milione di miglia da MVC.

sends ... requests to the server, which are then redirected to class methods

Ecco come funziona un controller in MVC. Non è chiaro, dalla tua descrizione, se il tuo modello è separato dal controller. Se il controllore passa le sue operazioni CRUD su un'altra classe (ad esempio Customer.update(customerData) ), e gestisce semplicemente l'azione di richiesta-risposta, suggerirei probabilmente di avere M e C sul posto - anche se in modo semplicistico.

each section of the App is a html page, ... and send back a JSON response to the client

Questi sono due tipi di visualizzazione comuni nei framework MVC. E hai sicuramente creato quel livello di astrazione, che è grandioso.

Al giorno d'oggi ci sono aspettative su un framework MVC che non necessariamente rientrano nel pattern MVC. Ad esempio, per renderlo un "MVC framework" appropriato, dovresti essere in grado di restituire i dati dal controller, insieme a un indicatore di quale tipo di vista (e magari vedere il modello) che vuoi che il framework costruisca da quei dati .

Quindi direi che non hai necessariamente creato un framework MVC ma stai seguendo qualcosa che si avvicina al pattern MVC.

Forse un termine più accurato per ciò che stai facendo è però SOA o architettura orientata ai servizi .

score 2 · Answer 2

La tua soluzione non è classica MVC, a mio parere, è molto meglio. Quello che hai, il mio giovane Padawan, è più come un approccio SOA .

Personalmente mi piace questo stile di architettura. Nel livello di business logic, viene ascoltato il messaggio SOA (Service-Oriented Architecture). Con il suo accoppiamento lento e la rimozione delle dipendenze implicite, il modello SOA offre flessibilità e uniformità attraverso la specifica di un'interfaccia di servizio definita, che nasconde i modelli di dominio e le tecnologie di implementazione.

Sfortunatamente, non esiste un progetto architettonico così chiaro per il livello di presentazione. Che cosa dicono le migliori pratiche del settore sullo sviluppo del front-end di un'applicazione? Qual è il modo migliore per connettere il front-end in modo ordinato all'interfaccia di servizio?

Il classico MVC soffre (imho) di almeno tre importanti difetti architetturali:

Non rispetta i dati, i dati inviati attraverso il filo sono dati altamente orientati alla presentazione e marcati.
Lo scambio di dati e la logica di presentazione sono strettamente accoppiati. Non è possibile spostarsi tra i passaggi del flusso di presentazione senza avviare le operazioni di scambio di dati. Le pagine Web vengono visualizzate in risposta alle richieste GET e POST inviate dal browser. Ancor peggio, ogni operazione di interscambio dati avviata dal browser impone un flusso di presentazione. Un famigerato risultato di questo stretto accoppiamento è il "problema del pulsante di ritorno del browser".
Il terzo difetto è che il modello web è richiesta / risposta. Non supporta gli stili di interazione peer-to-peer richiesti per la notifica degli eventi del server.

In questo frangente, si sarebbe tentati di concludere che AJAX è la risposta a questi problemi. Sfortunatamente, AJAX stesso è solo una capacità grezza e non un modello prescrittivo. È possibile utilizzare AJAX e creare ancora un orribile modello ibrido in cui il server Web continua a guidare Presentation Flow in risposta alle operazioni di Data Interchange e l'interazione AJAX si blocca da un lato, per così dire.

L'unico modello, che mi aiuta di più , è tuttavia basato su MVC. MVC sul lato server e lato client. La vista sul server è il modello nell'applicazione client, per così dire. Un'illustrazione:

La tua applicazione sembra seguire questo principio approssimativamente. Probabilmente hai avuto difficoltà a trovare una buona struttura nel tuo HTML e JS. Prova a guardarlo con questo approccio. Il tuo cliente Model è la vista laterale del server, i tuoi dati JSON. I tuoi binding e i tuoi eventi sono il tuo Controller . L'HTML è il tuo View . Prova a separare gli eventi e la logica dell'interfaccia utente dallo scambio di dati e troverai un modo molto efficace per creare applicazioni web.

score 0 · Answer 3

Sembra più un sistema a 3 livelli, in cui il livello di visualizzazione è lato client, il livello logico di business è nei servizi e l'archiviazione dei dati è nell'RDBM. (MVC si è evoluto da progetti a 3 livelli / 3 livelli)

Dovresti sapere che MVC è solo una parola d'ordine molto popolare in questo momento, come il 3 o il tier utilizzato fino a 3-5 anni fa. Non provare a metterlo sul tuo curriculum solo così sembra che tutti gli altri. L'app di livello N è più interessante per i grandi team di aziende:)