[Tech] Gestionali, Mysql e altre domande

[Christian Surchi]

On Wed, Feb 12, 2003 at 02:37:36PM +0100, Marco Ermini wrote:
> Allora, come (quasi) tutti dicono i professori universitari, "grazie per
> avermi posto la domanda" ;-)

Non l'ho fatto a caso, appunto. :)
 
> Anche se francamente credevo di sfondare una porta aperta...

E dai, siamo qui per imparare, altrimenti avremmo chiamato la lista
"guru", invece che "tech"!
 
> > Riferimenti esplicativi sui termini usati:
> > 
> > 
> > http://www.dict.org/bin/Dict?Form=Dict2&Database=*&Query=client-server
> > 
> > http://www.dict.org/bin/Dict?Form=Dict2&Database=*&Query=three-tier
> 
> Innanzitutto inviterei a non prendere definizioni da dizionari, tanto piu'
> online ;-) 

Scrivendo una mail ho riportato qualche definizione "accessibile", non
potevo fotocopiare libri o chissa' cos'altro... :)
Per la risposta comunque mi basavo sulle mia conoscenze.

> comunque, a parte le battute, immagino che si tratti piu' che altro
> di capire quale significato si danno alle parole. Io sto per riportare quello
> che generalmente si intende nel poco popoloso mondo degli analisi e degli
> architetti di sistema di cui da relativamente poco mi onoro di appartenere;
> uno sviluppatore, magari piu' incentrato sui dettagli, potra' ritenere i
> concetti forse logicamente piu' simili o sfumati di come non li veda io.

lungi da me essere uno sviluppatore!

> Questo, per dire che non pretendo di riportare una definizione da dizionario,
> ma solo di dire cosa "la maggioranza" in genere intende, ma ovviamente possono
> essere punti di vista.

per questo ho voluto precisare, visto che hai usato definizioni ben
precise che potevano non essere chiare e lampanti a tutti
 
> Innanzitutto, chiariamo che quando si parla di client/server e di three-tier
> si sta parlando ovviamente di analisi architetturale, ma soprattutto da un
> punto di vista logico ("logical architecture") e, se siamo gia' al three-tier,
> siamo nell'ambito della decomposizione del problema tramite la metodologia
> dell'analisi object oriented. Three-tier, come dice la parola stessa, e' un
> modello di analisi e progettazione di applicazioni che propaganda la
> separazione tra tre "livelli di business" come dicono i "dotti" dell'analisi,

lo dice pure il foldoc che citavo io, per la precisione :)

> ovvero la parte di presentation, quella di backend e l'RDBMS. Ripeto si sta
> parlando di analisi al fine dell'implementazione architetturale (casomai
> rimanderei a http://www.rational.com/products/whitepapers/461.jsp).

sssh, non farti sentire da Claudio... stai citando addirittura un testo
del '95 e lui ti dara' dell'obsoleto! ;)
 
> Quando si parla di client/server si sta parlando di un vecchio paradigma, in
> auge soprattutto in epoca "pre-web revolution", se mi passate il linguaggio da
>  hippie ;-), che significa in genere GUI + RDBMS (mi si potra' obbiettare che
> e' molto di piu'. Sono d'accordo nel senso che, in applicazioni abbastanza
> grandi e che subiscono variazioni spesso nel giro di una settimana, come
> quelle MIS, le scelte architetturali e di object-orientation si e' costretti
> comunque a farle; si veda l'eccellente whitepaper in proposito di Grady Booch
> "Objectifying Information Technology", che mi pare sia disponibile anche sul
> sito Rational).

Se lo trovo' lo leggero'! :)

> Parlando invece di three-tier si parla, *in genere*, di una frammentazione
> dell'architettura diversa. Intanto, siamo in un'epoca e in un contesto
> completamente differenti. C'e' stato il "boom" del web, e sono sorte nuove
> esigenze. In una applicazione client/server, il numero di utenti e'
> controllato (quantificabile in genere in centinaia o migliaia), la "distanza
> concettuale" tra l'RDBMS e il client e' poca, le applicazioni sono in genere
> modellate sul database (o sui database) che sono al "centro" del sistema, e
> consistono lato client in un applicativo installato localmente che puo' essere
> ragionevolmente cambiato ma e' sostanzialmente stabile, e su cui si pongono
> notevoli problematiche di software redistribution (per fare un esempio tecnico
> che forse mi fa comprendere di piu': il locking sull'RDBMS e' affrontato con
> nei modi piu' disparati, lato client, lato RDBMS o misto...). In caso di
> three-tier, si presuppone un contesto totalmente diverso: il numero degli
> utenti e' a volte imprevedibile (e puo' essere anche nell'ordine dei milioni),
> la composizione del backend e' estremamente variegata e composta di molte
> parti diverse che cambiano ed evolvono in continuazione. Infine, gli attori
> (nella terminologia di "attore" UML) in gioco sono in genere molto pochi in
> una applicazione client/server, in una three-tier possono essere molti (giusto
> per dire i primi che vengono in mente, i content provider, o i graphic
> designer).

Benissimo.
 
> Questo cosa implica dal punto di vista dello sviluppo? implica un fork
> abbastanza deciso nelle metodologie del processo di ideazione, progettazione,
> realizzazione, test e deploy delle applicazioni, che come e' facile intuire e'
> completamente diverso nei due casi - mi risultano ben pochi *casi reali* dove,
> per esempio, il paradigma MVC sia applicato ad una GUI di una applicazione
> client/server... ovviamente cio' e' teoricamente possibile, ma l'unico
> tentativo che ho visto fare e' stato in un progetto di IBM per Trenitalia a
> cui ho partecipato e che dopo un anno di giri a vuoto e' stato sospeso...
> mentre nel mondo web e' una prassi a dir poco abitudinaria, praticamente.

Non ti seguo adesso e non capisco dove tu voglia arrivare. :)
 
> Posso altresi' capire che, nell'ambito di applicazioni relativamente piccole,
> o comunque dove non c'e' stato un processo di razionalizzazione degli
> strumenti utilizzati per lo sviluppo, e da parte di programmatori che non
> hanno una particolare formazione sull'argomento (cosa assolutamente normale e
> giusta, non preoccupatevi, anche perche' in genere non e' il programmatore che
> si occupa di queste cose ;-) la percezione della differenza tra le due
> architetture sia relativamente poca (prima facevo una GUI e mi collegavo ad un
> DB, ora faccio delle pagine PHP e mi collego ad un DB: per lo sviluppatore si
> puo' quasi dire che siano cambiati solo il linguaggio e qualche altro
> strumento di sviluppo!!!). Questo magari succede a livello degli sviluppatori,
> oppure in realta' "limitate" da molti punti di vista o locali, che se gli
> parli di non dico di RUP, ma anche solo di UML, metodologie di analisi o
> architettura del software ti guardano a bocca aperta (o ti sputano nel viso
> ;-)

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.
 
> Ora, tornando allo scopo originale del thread, cosa significa questo in
> pratica ed in particolare per Umberto? che la sua applicazione non e' non
> sara' mai grande e complessa come il sistema demografico della Protezione
> civile o il servizio di raccolta dati elettorali della Prefettura e quindi
> sicuramente non servira' una analisi Vision 2000 per portarla da Access a PHP,
> pero' significa che personalmente preferisco *tenere in mente* che esistono
> architetture e paradigmi diversi, e preferisco rimanere in un ambito in cui io
> possa modularizzare il piu' possibile l'applicazione, in modo eventualmente da
> poterla facilmente rendere piu' generica o utile anche ad altri - a maggior
> ragione perche' potrebbe essere distribuita come GPL.

benissimo, "fai" come credi, appunto, ma la sostanza e la teoria che ci
stanno dietro secondo me non cambiano
 
> PS. scusate la prolissita', sara' la digestione dell'arancino che mi sono
> appena pappato :-P

mangia piu' leggero! :D

-- 
Christian Surchi, csurchi@debian.org, christian@firenze.linux.it |   ICQ     
www.debian.org - www.softwarelibero.it - www.firenze.linux.it    | 38374818
I'd like to meet the guy who invented beer and see what he's working on now.