Model-View-Controller

[amy]

Salve a tutti, ho un grosso problema..
Ho fatto un server pop3 in java e adesso dovrei dividerlo secondo il modello model-view-controller solo che non ne sono affatto capace..
C'è qualcuno in grado e che ha voglia di darmi una mano???
grazie a tutti

[Uno]

Salve a tutti, ho un grosso problema..
Ho fatto un server pop3 in java e adesso dovrei dividerlo secondo il modello model-view-controller solo che non ne sono affatto capace..
C'è qualcuno in grado e che ha voglia di darmi una mano???
grazie a tutti

server Pop3 con model-view-controller ?

Mi sfugge proprio il senso, comunque non ho tempo e java non è tra i miei linguaggi di programmazione preferiti, mi dispiace

Se hai tempo però spiegami la faccenda dell mvc per un server pop3 , mi interessa, magari imparo una cosa che potrebbe essere utile un domani.

[Stoned]

Se hai tempo però spiegami la faccenda dell mvc per un server pop3 , mi interessa, magari imparo una cosa che potrebbe essere utile un domani.

Mi accodo alla richiesta...
Il modello MVC è per le web application...anche perchè per quanto mi sforzi non riesco proprio a vedere la parte "view" di un server pop3
Ma non è che per caso intendevi un client web per la posta elettronica ??

[TheVice]

In tutto c'è una parte view. Se non lato utente c'è lato amministrazione . Se voglio, che so, una stats delle mail inviate, del traffico mail come banda consumata, potrei aver sviluppato un pannello ad-hoc che mi da la possibilità di creare accounts di posta e chi più ne ha più ne metta.
Anche se non ci fosse tutto ciò il modello sarebbe ugualmente valido essendo comunque un insieme di blocchi correlati (ad esempio il blocco View semplicemente risponde NULL). Poi se ha cannato modello questo non possiamo dirlo senza conoscere i dettagli funzionali della sua applicazione.

[Uno]

Poi se ha cannato modello questo non possiamo dirlo senza conoscere i dettagli funzionali della sua applicazione.

Infatti non mi ero permesso, ma ero curioso di sapere in che senso view .
In ogni caso, forse perchè mi sono un pò distaccato dai modelli di programmazione windows ed avvicinato più ai modelli linux, per me un server deve essere nudo e crudo e configurabile tramite file config testuali, poi a questo ci si può interfacciare e/o costruire un programma di amministrazione più o meno visuale.
Con questo non ritengo meno valido il modello, generalmente windows, in cui il server ha tutto dentro e spesso non può essere interfacciato a null'altro, a me non piace, lo trovo pure meno potente, ma sono gusti personali.

[TheVice]

Infatti non mi ero permesso, ma ero curioso di sapere in che senso view .
In ogni caso, forse perchè mi sono un pò distaccato dai modelli di programmazione windows ed avvicinato più ai modelli linux, per me un server deve essere nudo e crudo e configurabile tramite file config testuali, poi a questo ci si può interfacciare e/o costruire un programma di amministrazione più o meno visuale.
Con questo non ritengo meno valido il modello, generalmente windows, in cui il server ha tutto dentro e spesso non può essere interfacciato a null'altro, a me non piace, lo trovo pure meno potente, ma sono gusti personali.

Non so fino a che punto sia corretta l'affermazione che sto per fare, ma al di fuori del modello di rappresentazione dei dati (sia input che output) la parte "view" del modello la ritengo valida anche per tool configurati attraverso file .cfg e simili. Se ci rifletti cambia l'interfaccia ma non il modello, in ingresso passi i dati via file.cfg in uscita hai i log.
Il modello resta valido anche se hai interfaccia NULL ecco perchè costituisce un design pattern. A mio personale avviso è abbastanza discutibile associarlo in senso stretto ad un'interfaccia visuale, ne limiterebbe mostruosamente l'applicabilità come modello.

[Uno]

Non so fino a che punto sia corretta l'affermazione che sto per fare, ma al di fuori del modello di rappresentazione dei dati (sia input che output) la parte "view" del modello la ritengo valida anche per tool configurati attraverso file .cfg e simili. Se ci rifletti cambia l'interfaccia ma non il modello, in ingresso passi i dati via file.cfg in uscita hai i log.

Questione di punti di vista, secondo la tua affermazione è una view anche l'editor di testo o la shell che uso per modificare il config di un server, anzi lo sarebbe anche la shell se la uso per killare quel server o per riavviarlo. Per me invece sono un'altro software, distinto e separato che può essere usato per controllare in qualche maniera quel server.

Il modello resta valido anche se hai interfaccia NULL ecco perchè costituisce un design pattern. A mio personale avviso è abbastanza discutibile associarlo in senso stretto ad un'interfaccia visuale, ne limiterebbe mostruosamente l'applicabilità come modello.

Sbaglierò io ad associare la parola view (vista) a qualcosa che deve essere visuale... ma non sei riuscito a convincermi
Nessuno vuole modificare il modello mvc, mi chiedevo se era applicabile ad un server, soprattutto (e questo con il ragionamento di dopo, prima non ci avevo pensato) che non sia progettato secondo i modelli usuali windows in cui quasi tutto ha un interfaccia.
Se non c'è la vista allora è un modello mc, no?

[andrea.paiola]

Sbaglierò io ad associare la parola view (vista) a qualcosa che deve essere visuale...

si anche secondo me sbagli... hai presente le views di MySQL?
ecco: viste nel senso di modi di vedere i dati, non nel senso di interfaccia.
Posso avere una vista con output XML e non mostrarla all'utente, per esempio.

[Uno]

si anche secondo me sbagli... hai presente le views di MySQL?
ecco: viste nel senso di modi di vedere i dati, non nel senso di interfaccia.
Posso avere una vista con output XML e non mostrarla all'utente, per esempio.

Aspè Andrea, quelle sono viste e basta, non sono una parte di mvc, sono viste dal punto di vista del software, ma se parliamo di mvc il pattern è quello.
Siccome non sono ingegnere informatico, ma autodidatta per quando riguarda il pc, mi aiuto con le definizioni di wikipedia (che non considero sempre attendibili, ma in questo caso mi sembrano in linea con tutto quello che ho sempre letto in giro.

Dalla wikipedia italiana

Il pattern è basato sulla separazione dei compiti fra i componenti software che interpretano tre ruoli principali:

• il model contiene i dati e fornisce i metodi per accedervi;
• il view visualizza i dati contenuti nel model;
• il controller riceve i comandi dell'utente (in genere attraverso il view) e li attua modificando lo stato degli altri due componenti

Questo schema, fra l'altro, implica anche la tradizionale separazione fra la logica applicativa (in questo contesto spesso chiamata "logica di business"), a carico del model, e l'interfaccia utente, a carico del view e del controller.

Ma la versione inglese secondo me è meglio

Model-view-controller (MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC, the model represents the information (the data) of the application and the business rules used to manipulate the data; the view corresponds to elements of the user interface such as text, checkbox items, and so forth; and the controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.

e ancora

Model
The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items).
Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.
View
Renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.
Controller
Processes and responds to events, typically user actions, and may invoke changes on the model.

View
Renders the model into a form suitable for interaction, typically a user interface element.

Tipicamente un interfaccia utente, ma comunque una qualche forma per interagire con l'applicazione, che però (questa è una mia considerazione) sia sempre parte dell'applicazione, non esterna alla stessa.


Poi, posso essere in errore, ma datemi altri dati su cui ragionare.

[Marco Borromeo]

La mia visione di un MVC su un server è

• - Model: si interfaccia al filesystem, o a qualsiasi altro storage dove risiedono fisicamente le email, e fornisce le funzioni per accedervi (es: dammi tutte le mail di xyz / dammi tutte le mail nuove di xyz / setta la mail xyz come letta / ecc).
• - Controller: interpreta i comandi ricevuti dal client, effettua query tramite i modelli, e ritorna i dati da mandare al client.
• - View: riceve i dati dal controller, e li "formatta" secondo le RFC in vigore. Riceve i dati dal client, ne fa il parsing (è la view che veramente si occupa del parsing?) e li passa al controller.

Cioè, dal mio punto di vista la "user interface" è di fatto il protocollo di comunicazione tra server e client.

Ciao,
marco.

[Stoned]

In tutto c'è una parte view. Se non lato utente c'è lato amministrazione . Se voglio, che so, una stats delle mail inviate, del traffico mail come banda consumata, potrei aver sviluppato un pannello ad-hoc che mi da la possibilità di creare accounts di posta e chi più ne ha più ne metta.
Anche se non ci fosse tutto ciò il modello sarebbe ugualmente valido essendo comunque un insieme di blocchi correlati (ad esempio il blocco View semplicemente risponde NULL). Poi se ha cannato modello questo non possiamo dirlo senza conoscere i dettagli funzionali della sua applicazione.

Scusa, ma credo tu abbia fatto un po' di confusione: se devo fare un pannello (esempio da te citato), il model è la parte di interfacciamento con i dati (ovvero, quello che legge effettivamente il file delle stat, che crea gli account, ecc), la view è il pannello di controllo che tu visualizzi (sia esso web o tramite semplice gui) e il controller è quello che elabora ogni richiesta che fai tramite la view: da un punto di vista prettamente logico, questo non ha alcun collegamento con il server, ma solo con i file di configurazione, di log, ecc...
Puoi leggere e modificare parametri del server, ma in realtà l' MVC è applicato ai parametri, non al server stesso...

[Uno]

La mia visione di un MVC su un server è

• - Model: si interfaccia al filesystem, o a qualsiasi altro storage dove risiedono fisicamente le email, e fornisce le funzioni per accedervi (es: dammi tutte le mail di xyz / dammi tutte le mail nuove di xyz / setta la mail xyz come letta / ecc).
• - Controller: interpreta i comandi ricevuti dal client, effettua query tramite i modelli, e ritorna i dati da mandare al client.
• - View: riceve i dati dal controller, e li "formatta" secondo le RFC in vigore. Riceve i dati dal client, ne fa il parsing (è la view che veramente si occupa del parsing?) e li passa al controller.

Cioè, dal mio punto di vista la "user interface" è di fatto il protocollo di comunicazione tra server e client.

Ciao,
marco.

Posto così il ragionamento ha già un senso, però qualcosa non mi convince, perchè ho idea che la view del modello mvc (non altri tipi di vista fuori del pattern) debba dare i dati già in forma usabile dall'user.
Invece quando ricevo la mail dal server non la leggo direttamente nel sorgente (in questo caso non ci sarebbero problemi, visto che è in formato testo, ma pensiamo a casi più complicati) la scarico, interpreto e leggo con un client.
Altrimenti l'mvc potrebbe essere anche qualcosa tipo quello che nel film matrix usavano per controllare appunto matrix. Ma a questo punto come detto sopra non servirebbe il pattern mvc, sarebbe sufficiente un mc e io utente in qualche modo devo interpretare i dati che il software elabora.

[valent]

Salve a tutti, ho un grosso problema..
Ho fatto un server pop3 in java e adesso dovrei dividerlo secondo il modello model-view-controller solo che non ne sono affatto capace..
C'è qualcuno in grado e che ha voglia di darmi una mano???
grazie a tutti

In pratica dovresti riscrivere il codice e usare uno dei nuovi (relativamente parlando) framework tipo Java Server Pages o Apache Struts. Non è una cosa facile, perché (oltre a conoscere Java EE) devi imparare molte cose.

[andrea.paiola]

Posto così il ragionamento ha già un senso, però qualcosa non mi convince, perchè ho idea che la view del modello mvc (non altri tipi di vista fuori del pattern) debba dare i dati già in forma usabile dall'user.
Invece quando ricevo la mail dal server non la leggo direttamente nel sorgente (in questo caso non ci sarebbero problemi, visto che è in formato testo, ma pensiamo a casi più complicati) la scarico, interpreto e leggo con un client.
Altrimenti l'mvc potrebbe essere anche qualcosa tipo quello che nel film matrix usavano per controllare appunto matrix. Ma a questo punto come detto sopra non servirebbe il pattern mvc, sarebbe sufficiente un mc e io utente in qualche modo devo interpretare i dati che il software elabora.

vabbè anche l'html mica lo leggi

[Uno]

vabbè anche l'html mica lo leggi

Anche questo ha un senso, ci penso un momento