[Tech] Gestionali, Mysql e altre domande

[Christian Surchi]

On Wed, Feb 12, 2003 at 05:10:05PM +0100, Marco Ermini wrote:
> > sssh, non farti sentire da Claudio... stai citando addirittura un testo
> > del '95 e lui ti dara' dell'obsoleto! ;)
> 
> Sta in una raccolta di scritti di Booch, che comunque non e' un sito web.
> Booch e' uno degli inventori dell'UML, e nel '95 stava gia' sviluppando il suo
> linguaggio di modellazione, che poi e' confluito nell'UML. Booch era
> decisamente un pezzo avanti nel 1995...

Claudio e' dieci anni avanti... ed e' ora che tutti lo sappiano! ;-)

> [...]
> > Non ti seguo adesso e non capisco dove tu voglia arrivare. :)
> 
> Lasciamo perdere Trenitalia, e' meglio :)

"arrivare" poi... :D

> [...]
> > si, ma questo non mi pare che cambi la sostanza...
> > puoi aggiungere livelli di astrazione o mettere sistemi e modalita' di
> > comunicazione diverse (e quante ne vuoi) tra l'utente e i dati, pero'
> > non mi pare che questo "escluda" la presenza di client e server in senso
> > esteso.
> [...]
> 
> Il problema del contendere forse e' qui ;-)
> 
> Non e' una questione di aggiungere livelli di astrazione, e' vedere (o meglio,
> la capacita' di vedere) il *processo di sviluppo* di un'applicazione (raccolta
> e formulazione dei requisiti, analisi, progettazione, sviluppo, test, deploy),
> quello che la Rational chiama appunto RUP ovvero "unified process". Da un
> punto di vista architetturale, se stai parlando di client/server parli in
> sostanza di GUI + RDBMS (scusa se semplifico...), 

appunto, e' quello che dicevo... io intendo il client-server come un
modello, legato magari ad una visione "ristretta", ma lascio al momento
perdere quelle che sono le realizzazioni concrete di volta in volta
scelte. 

> se parli di n-tier parli di
> un'altra cosa (per esempio, se stiamo parlando di Web, parliamo di un backend
> applicativo che genera un meta-contenuto connettendosi ad un RDBMS, fa parsare
> il meta contenuto da un application server che genera un layout per l'utente,
> che lo serve tramite un web server). Quindi, stiamo parlando di due modi di
> operare (nel senso di progettare, sviluppare, testare ecc. ecc.) con paradigmi
> completamente diversi - e per l'appunto, caratterizzati in sostanza da una
> piu' o meno spiccata improvvisazione nel primo caso, mentre oggi si tende ad
> eliminarla il piu' possibile (ti assicuro che il paradigma perfetto al giorno
> d'oggi, nel Gantt principale del piano di progetto complessivo, e' 50%
> progettazione, 25% sviluppo e 25% test: ti ho detto tutto).

mi fa piacere anche conoscere queste esperienze e questi dati che non
sperimento al momento di persona, o meglio li sperimento poco e male, ma
questo e' un altro discorso! ;)
 
> E' chiaro anche a me che se vai a vedere *il microscopico dettaglio* dell'EJB
> container (o il WinDMA o come cippa si chiama in casa MS) che in una sua
> *istanza* particolare su una particolare CPU ed in una certa zona di RAM
> richiama *una certa istanza* del driver JDBC ecc. ecc., alla fine dei giochi
> c'e' un client che si connette ad un server tramite un protocollo - pero' se
> sei uno sviluppatore o un architetto aggiornato questo non ti interessa piu'
> come all'epoca del client/server, perche' te pensi a creare dei *componenti*,
> perche' ormai si sviluppa object oriented! (ora sto un po' estremizzando, nel
> senso che se faccio un sito senza grosse pretese anche io faccio qualche
> minchiata con cut&paste di PHP, senza troppe pretese... per carita').

sono due punti di vista diversi, ma le visioni secondo me si integrano
 
> Quindi dipende dal punto di vista. Quando ho detto che il "client/server e'
> morto e sepolto" mi sono fatto trascinare dall'entusiasmo per il nuovo, questo
> lo devo ammettere francamente :-P e su questo hai totalmente ragione...

Benissimo, allora siamo anche troppo d'accordo (e' grave questo? ;)) e
se rivedi la mia risposta io ho criticato proprio quello fornendo al
massimo i primi "riferimenti" (sottolineo) a due concetti esposti che
possono non essere banali per tutto (e come abbiamo visto non lo sono
neanche per noi! ;)). Lungi quindi dall'essere esaustivo.

-- 
Christian Surchi, csurchi@debian.org, christian@firenze.linux.it |   ICQ     
www.debian.org - www.softwarelibero.it - www.firenze.linux.it    | 38374818
"The C Programming Language -- A language which combines the flexibility of
assembly language with the power of assembly language."