Newsgroup: it.comp.lang.visual-basic
Titolo: [TEORIA] come pianificare un prog "multi tutto"...anche con vb.net!

Ue raga come va? ...non mi son dimenticato ...è che gli impegni mi
portano altrove...comunque ogni tanto faccio qualche incursione!
Ce ne son mille di NG per NET e programmazione...ma io son fedele ai
cervelli che conosco!
Il problema è questo...come pianificare un programma multi
tutto...multi utente multi db multi client???
Esempio:
Ho un programma che gestisce una lista nomi (famola facile)...ad un
livello "base" ...il DB e Access ed accede una postazione soltanto
Evolvendo potrebbe accadere che il DB diventa SQLserver...e rimane un
utente
e poi si aggiungono 10 postazioni....
Mutando si potrebbe scegliere un DB postgresql....e sempre 10
postazioni....
Incarognendosi...10 postazioni son: 5WinXP 3 MACos 2Linux
La mia solita classica soluzione è sempre quella(in VB6)....un
programma su ogni postazione che si occupa di formattare i risultati
che richiede ad un altro programma i dati....questo componente/
programma...fisicamente connette e chiede al db i dati che poi me li
rispedisce sitto forma di recordset
Un altra soluzione è fanc a tutto....installi la parte "server" sotto
IIS e usi un web server per inviare i dati ai client...che
visualizzano dentro il browser (non installando nulla sul pc del
client che non sia un browser)
Però mi domando...sta soluzione funzionante...è frutto di compromessi
ed esperienze personali.
Volendo affrontare la cosa in maniera organica (e con NET) ...e non
avendo io una formazione universitaria come fare?
Io mi immagino una soluzione frutto della mia empiricità:
A) Una serie di classi che si occupano di prendere la risposta di B e
di presentarla a schermo
B) Una componente installato su un server che si occupa di ricevere le
richieste e di smistarle/tradurle nel formato giusto per il db
B1) Una interrogazione al server
B2) Un "impacchettamento" della risposta disponibile per il client
C) Un server con installato il DB
Pensavo di usare come "collante" un file XML
La richiesta del client è in formato XML...la risposta di B è in
formato XML...
Solo che può capitare che il client mi richieda la lista completa dei
nomi (es. per una spunta manuale una tantum dei nominativi validi in
archivio) ...si genera un file XML enorme...
da mie prove fatte ....se XML è comodo...non è che brilli in
prestazioni (fidandosi solo sull'hard disk...è pur sempre un file di
testo) quando i record sono tanti!
Il file Xml sarebbe comodo perchè anche su altre piattaforme si genera
molto facilmente (es...php dentro una pagina web...)
Insomma...che ne pensate?...illuminatemi un po!

In azienda lavoriamo su un aplicativo ASP con IIS e SQL Server.
Con 25 postazioni ed un database di circa 3 giga.
All'interno oltre 50.000 curriculum e 20.000 Email, più i report (tutti 
in html), ecc...
Gira senza problemi su un server P4 3.0 Ghz e 1 Giga di RAM
All'interno non è stato usato XML (il software è stato realizzato 
originariamente alcuni anni fa).
Per le liste molto lunghe di utenti ti consiglio di troncare i dati ad 
un valore accettabile (es 500 utenti per pagina) e suddividere tutto su 
più pagine e di poter garantire la totale scalabilità (aggiungi 
postazioni con zero configurazione) e minore rottura di balle negli 
aggiornamenti.
Questo ti consente di essere multipiattaforma e di avere delle belle 
cosine con il DOM sfruttando AJAX (e qui magari giochi un pò con l'XML).
Il mio consiglio è usare ASPX o al massimo PHP. Lascia perdere ASP che 
non è più supportato.
bye