Newsgroup: it.comp.lang.visual-basic
Titolo: [Teoria]...a proposito del metodo di sviluppo multi utente

Se mi prendo i miei libri mi dicono di fare tutto in 3tier
Ossia parlando volgare:
dividere in 3 strati
a)Il client
b)Il core business
c)Il database
Se spacco tutto in 3 ho determinati vantaggi
a) Il client può essere eterogeneo....sia multi SO che più o meno
complesso
b) Cambiare ed upgradare il programma è "abbastanza" agevole e
indolore
c) Cambiare manutenere il database è agevole. Inoltre non costringi ad
avere "mostri" di server
E so anche che tutto si può "rimbastardire" più o meno
Ad es.
Usando SQLserver si può andar giù più o meno pesantemente di stored
e mischiare un po strato businness e strato dati.....
Poi ....
ragionando con un collega...mi dice che lavora in un ced con varie
filiali sparse per l'italia e per il mondo...e che sono in 6
programmatori....
fiuu dico io....
per la realtà locale 6 programmatori (più uno schiavetto e 2 tecnici)
ne macinano di codice!
Ma che dovete fare sviluppare un nuovo programma?
No no il programma è un po di tempo che è stato sviluppato....
è che sai manutenere 2000 stored!
EH! 2000 stored??? ho capito bene?
Beh si...sai noi non crediamo molto nella suddivisione canonica
...abbiamo sviluppato un "componente per la remotizzazione del db" (sic
! qualsiasi cosa voglia dire) e abbiamo sviluppato un client che non è
solo client ma integra anche una parte business
mia obiezione: ma non è un inferno in terra???
Beh che vuoi...siamo dei ganzi...abbiamo un bel mostro di server...e
poi una stored praticamente per tutto!!!
Io ho poca esperienza di realtà "grosse e distribuite"....
ma secondo voi...secondo chi ha QUESTA specifica esperienza (AAA
astenersi perditempo )...
è corretto andar giù così pesantemente di stored e implementare
business anche nel client???
Secondo me no!...di fatto leghi tutto ad una specifica configurazione e
ti incasini alquanto la vita per la manutenzione!
Però il collega mi obiettava che forse sarà anche vero ma le
prestazioni sono molto migliori!
Di cosa se ne faccia di un secondo in meno di visualizzazione report
l'ufficio di Sidney non lo so!
Cosa ne pensate?

 Se mi prendo i miei libri mi dicono di fare tutto in 3tier
zac> Cosa ne pensate?
Per la cronaca ...tutto il "pacchetto monstre" l'hanno sviluppato in
Delphi e SqlServer....
ma
mi interessava il vostro parere concettuale!...e pratico...sul vissuto!

 business anche nel client???
Bè, 'corretto' non è la parola esatta....non si può dire se la cosa è
giusta o sbagliata....semmai se è conveniente o meno per una data
architettura...
Cmq, io concordo con te...per grandi sistemi distribuiti occorre
effettuare una suddivisione. Inglobare molti 'strati' porta ad avere un
codice difficilmente mantenibile (che non è cosa da poco)!
Per quello che riguarda la velocità, anche qui dipende....
Il tuo collega dice che nel suo modo è più veloce....bè, non è detto...
magari è il modo in cui hanno scritto il loro codice che porta la loro
architettura ad essere + veloce in 2tier!! Ricorda che il livello
business solitamente non gira sulla stessa macchina del client!!!
Ciao!
Daniele.
-- 
Free As In Freedom
www.fsf.org

 business solitamente non gira sulla stessa macchina del client!!!
infatti è proprio questo il punto cruciale...
lo capisco anche io che se "inglobo" il business dentro il DB (perchè
secondo me questo è fare 2000 stored)...probabilmente le prestazioni
dipendono direttamente dalla potenza del pc...pc...del mainframe altro
che pc!!!
Però continuo a pensare che sia follia...una "comoda" follia
prestazionale...un incubo per un programmatore!
Certo che allora mi si apre un altra considerazione....
La comoda integrazione che consentono questi motoriDB moderni...che
oramai archiviano ANCHE i dati ma ti mettono a disposizione di fatto un
linguaggio di programmazione interno che rende difficile parlare ancora
di 3tier (ed infatti aumentano i tools anche grafici di debug per
questi db)
DI fatto usi un qualsiasi linguaggio per implementare un
client...casomai il più carino e colorato possibile...e chiami
direttamente quintali di stored e quant'altro sul server...
un 3tier vestito da 2tier
Sbaglio a dir così?
Ma è davvero umanamente manutenibile una cosa del genere?
probabilmente no...se ci stanno 6 programmatori fissi!...ma può darsi
mi sbagli!

 business anche nel client???
Premettiamo, giusto per fare accademia, che le SP sono oramai 
supportate da tutti i dbms, quindi una eventuale migrazione sarà 
pesante, ma non strutturalmente impossibile.
Da un punto di vista operativo, l'assegnazione alla SP della parte 
logica è tanto più vantaggiosa quanto più numerose sono le dinamiche 
che si possono presentare.
Del resto, inutile negarlo, se una cosa va fatta, o la fa il client 
(sia esso remoto o su un application server) o la fa il dbms. E se la 
fa il client, il rischio che possano coesistere due versioni diverse, o 
che occorra fare aggiornamenti di massa anche solo per allungare di un 
char un campo del db, è elevata.
Le 2000 SP (numero grosso, ma se non fossero 2000 SP sarebbero 2000 sub 
all'interno del client), consentono al CED di poter inibire, in un 
secondo, una determinata funzionalità a tutti, se si trova un problema, 
lasciando tutto operativo. Consente di sistemare il problema stesso in 
maniera definitiva e senza doversi preoccupare di chiedere di riavviare 
il client, ecc...
Da un punto di vista prestazionale, siamo ovviamente a tutt'altro 
livello. Innanzitutto possiamo far lavorare un telefono cellulare con 
performance paragonabili ad un pc, possiamo avere la stessa identica 
logica applicativa contemporaneamente aggiornata sul client della 
contabilità, su ASP, sul lettore barcode wifi, ecc...
L'altro punto che correttamente segnali è quello di avere logica SIA 
sul dbms SIA sul client. Qui occorre fare attenzione. Noi lasciamo al 
client il controllo di validità del dato (l'importo deve essere 
numerico, il checksum del barcode deve essere giusto, ecc...), ma poco 
altro. Il resto, va tutto su SP.
Un aneddoto: la settimana scorsa, ho fatto MER+GIO+VEN in 'visita 
pastorale'. Ho girato tutti gli insediamenti italiani di un cliente 
(Francia e Russia li lascio al loro CED), a controllare che tutti i 
client fossero aggiornati, che gli utenti sapessero usare le nuove 
funzionalità, ecc...
E sai cosa ho trovato?
Beh, siccome noi distribuiamo le applicazioni come ActiveX su pagine 
HTM, accade che a volte si rilascino delle versioni Beta, usando 
indirizzi paralleli, del tipo 
http://server/applicativo/beta_1_3/
. Col 
tempo, si era generata una dozzina di queste directory virtuali Beta. 
Solo che ogni tanto veniva comunicato un indirizzo beta anche ad un 
utente non beta tester, questo si creava un collegamento sul desktop, e 
da lì in poi continuava ad usare quel link. Solo che noi andavamo 
avanti a rilasciare le release successive sul link ufficiale, e 
quell'utente non veniva informato che era concluso il test.
Ebbene, c'erano un ventina di utenti che usavano versioni del client 
'unofficial', vecchie anche di un paio d'anni. Graficamente diverse, 
alcuni campi non gestiti, ecc..., ma TUTTO funzionava correttamente. Il 
db era cambiato, c'erano tabelle nuove, regole di integrità 
referenziale nuove, dati che non venivano più gestiti in una tabella 
bensì in un'altra. Ma usando le SP, e garantendo ogni volta la 
retrocompatibilità di ciascuna (i parametri nuovi sono sempre 
Optional), anche i client vecchi e dimenticati erano in grado di 
operare sul db senza avere o generare problemi.
Ciao
Alberto
-- 
A questo punto hanno trovato un muro,
un muro duro, molto molto duro,
che siamo noi.

 che si possono presentare.
zac
Innanzi tutto grazie della risposta!
Sempre per fare accademia ma comunque per crescere culturalmente....
Quindi non posso avere la moglie ubriaca e la botte piena:
Se cercherò la maggiore flessibilità avrò una serie di client (che
validano l'input e lo presentano, ricevono un report e lo inviano alla
stampante se c'è e stop)...dal pc al palmare al telefonino al
frigorifero hitech....
che interrogano un server (via inter/intranet)...che si occupa di
chiamare un(più di uno) server-database.
In questo modo cambio un campo sul DB...devo aggiornare l'application
server....e i client per mostrare il nuovo campo.
Posso però integrare Application dentro il DB...è quello che si fa
con le stored...lasciando la formattazione e la gestione delle stampe
al limite ad un programmillo dedicato che lo distribuisce ai vari
client (addirittura integrandolo nel client come mi parva di capire
abbian fatto sti tizi)......
Però facendo così mi lego ad un prodotto...ad un dialetto SQL...etc
etc
In buona sostanza mi chiedo..anzi ti chiedo visto che io sono
ignorantone....
diventa lavoro da CED e non da programmatore!
Nel senso che tutto quello che sviluppo rimane in quella specifica
azienda e non è trasportabile come "pacchetto gestionale"....cosa che
si può fare seguendo una logica 3tier ???(ma usando SQLserver o altro
db solo per operazioni di Creazione/Cancellazione/Modifica/Ricerca)
Volevo solo conferme su questo...tanto per fare accademia!
Visto che son qui malaticcio a non saper che fare!
:o)

qualsiasi cosa voglia dire)
Sempre che non abbia capito male, cerca .Net remoting in msdn...in pratica 
(cito) " ...fornisce una struttura che consente agli oggetti di interagire 
fra loro su domini di applicazioni.
Umbe 

 c)Il database
Ad ogni problema la sua soluzione.
I libri non passano il loro tempo a sviluppare software correndo dietro ai 
clienti.
I libri vivono in una loro realta' parallela.
Per il tuo progetto il 3-tier e' migliore? Applicalo.
Non lo e'? Non applicarlo.
Non esiste un meglio/peggio, esiste cio' che e' meglio in un dato ambito.

 Visto che son qui malaticcio a non saper che fare!
Un bel pornazzo, e pedalare.


 db solo per operazioni di Creazione/Cancellazione/Modifica/Ricerca)
E su questo, caro Wodka, io non sono d'accordo: tu puoi anche
avere un sistema NTier che nell'AS vede una forte presenza di
StoredProcedures, non c'è un vincolo su questo.
Quindi tu puoi *ancora* avere vantaggi da un accesso a N livelli,
*anche se* usi molte SP.
Chiaramente, il costo di migrazione nel caso di 2000 SP è molto,
molto, molto alto, ma perfettamente sostenibile da alcune realtà.
Tutto IMHO.
Andrea

Andrea Raimondi ha scritto:
approfitto per ringraziare tutti quelli che hanno contribuito a questa
discussione...di cui io ero il più ignorante ed inadeguato!
Credo che sia un esempio edificante e scolastico di quello che
potrebbero esprimere i NG aldilà del solito scontato "Aiuto non ho
l'help di vb6...o sul solito decompilatore"