Newsgroup: it.comp.lang.visual-basic
Titolo: [?]Consiglio programma client server come cosa

Quale è il metodo migliore per realizzare un programma client server tipo
gestionale (indipendente numero utenti) ? Chiedo questo perchè ho visto
alcuni programmi che per comunicare scrivevano i dati da passarsi in un db
(probabilmente è un client server 'sporco') mentre altri che utilizzano il
winsock (client server puro ?). A parte la precisazione solitamente che cosa
si utlizza per scrivere un programma client server che utilizzi un db
(access, mysql, sql server altro) e che sia indipendente dal numero di
client (fermiamoci ad una intranet) ?

 client (fermiamoci ad una intranet) ?
Un' info:
VB6
ADO
o
VB.NET
ADO.NET
XML Schema
giuseppeD

 client (fermiamoci ad una intranet) ?
Di solito si utilizza winsock.
Io preferisco utilizzare un ActiveX-exe che faccia da bridge tra le 
varie app.
Se hai VB enterprise puoi creare questo oggetto "server" in modo da 
essere richiamato da remoto, quindi instanziarlo da un solo PC per tutti 
gli utenti collegati.
Se il tuo problema č la base dati server, qualsiadi DBMS si gestisce la 
cosa per i fatti suoi, e a te basta collegarti.
Non č molto chiaro cosa intendi per essere indipendenti dal numero di 
utenze.
Ciao


Occorre in primo luogo definire il concetto di Client/Server
Nel significato comune Client/Server è relativo alla programmazione
orientata alla gestione dei dati. Quello che occorre è fondamentalmente
un sistema di gestione dati che offra delle interfacce che accettano comandi
e restituiscono risultati usando un canale di comunicazione fra due
processi.
Access quando usato con i formati nativi Mdb i non rientra nella definizione
di sistema Client/Server dato che ogni istanza del programma accede
direttamente
alla struttura di memorizzazione persistente dei dati (il file mdb).
SQLServer invece è Client/Server a tutti gli effetti.
In tutte le versioni di Windows viene distribuito un modulo denominato
MDAC (Microsoft Data Access) che implementa le interfacce di tipo COM
rispettivamente ODBC, OLEDB ed ADO, deputate proprio alla gestione dei dati.
Quello che ti occorre è uno strumento per poter usare queste interfacce.
A questo punto puoi scegliere quello che più ti aggrada.
VB 5 o 6, Delphi, Access  (usando le tabelle allegate o le applicazioni adp
o programmando
direttamente l'uso delle interfacce ADO) o comunque impiegando qualsiasi
linguaggio in grado di instanziare oggetti COM.
Di norma le comunicazioni fra i driver di interfaccia (o provider) OLE-DB o
ODBC
e sistema di gestione dei dati avviene usando il protocollo TCP (socket).
Ma questo è solo un dettaglio di implementazione.
Nell'ambito della cosiddetta programmazione Client/Server devi introdurre
anche il concetto di comunicazione sincrona o asincrona. E' per questo
che molte volte delle applicazioni non direttamente orientate alla gestione
dei dati usano un db (o qualcosa di simile, come un gestore di messaggi
accodati)
come mezzo di scambio messaggi.
-- 
-- 
Saluti e salute a tutti.
________________
Gabriele Del Giovine [Microsoft MVP] - Windows 2000 - Windows NT 4.0
- Le informazioni fornite in questo messaggio sono fornite
  senza vincolo di garanzia e senza responsabilità alcuna.

 ha scritto nel messaggio
news:mnZ2b.12780$w8....@news.edisontel.com...

Appoggio i colleghi che ti hanno risposto prima di me e aggiungerei lo
studio e l'utilizzo di DCOM oppure COM+ (in caso di sviluppo su Internet).
DCOM in breve di permette di evitare di impazzire con i controlli MS Socket
e le relative API dandoti la possibilità di concentrati sulla distribuzione
del carico dei processi (e mille altri problemi :)
Saluti

 tipo gestionale (indipendente numero utenti) ?
Cercando di entrare nel (presunto) merito della richiesta...:
Client/Server, tecnicamente parlando, è un concetto che poco dipende da te,
ma esclusivamente dagli strumenti che utilizzi. Per esempio, Access, si
vocifera, non è C/S, mentre SQL Server, si vocifera, sì.
Client/Server, realisticamente (e non solo tecnicamente) parlando, in
ambiente di 2 o più utenti sullo stesso server, ovvero ospite di database, è
un concetto che dipende _esclusivamente_ da te, non dagli strumenti che
utilizzi, anche se si fregiano del'aggettivo "Client/Server".
In altre parole, se devi fare una qualsiasi cosa (gestionale o altro) che
presuma la (apparente) contemporaneità di 2 o più utenti, fregatene degli
aggettivi e pensa agli immensi pasticci (umani, umanissimi, pur senza
pensare alla mala fede o al sabotaggio) che possono accadere quando due o
più utenti possono/vogliono fare cose che, se non ben progettate, possono
entrare in conflitto. Risolvi questo, concettualmente e sulla carta
(insomma, non ti serve niente di informatico) e poi, indipendentemente da
questo, scegli gli strumenti che, eventualmente, mostreranno i loro
vantaggi/svantaggi.

 come mezzo di scambio messaggi.
Quoto tutto, solo per chiedere una realistica traduzione. Non contesto nulla
(beh, forse la prima frase, che ho messo fra #, sě, decisamente), ma davvero
non ho capito niente. Ovviamente ammetto di avere poca teoria, ma (anche se
poco puň contare) molta pratica, sě.

Lupo wrote:
[...]
Bentornato! ;-)

 Bentornato! ;-)
Ehm..., lo confesso, "mi ci stanno spingendo" da altra parte.
Non cambio idea, ma, forse, sto andando per esclusione.
Lo so che è da stronzo (sì, lo so!), ma almeno, qui, "stronzo" (per se
stessi) si può scrivere impunemente.
Di là, pare che "litrozzo" non sia ben visto...
Mamma mia, ragazzi. Come si dice ? "L'è un mondo difficile" e io aggiungo
"ma che palle!"

 Di là, pare che "litrozzo" non sia ben visto...
Adesso sono curioso: di là dove? :)
Ciao

 Di là, pare che "litrozzo" non sia ben visto...
E dove te ne vai ?

 Di là, pare che "litrozzo" non sia ben visto...
Di là dove? :?

 Adesso sono curioso: di là dove? :)
microsoft.public.it.vb
Distratto!

 Di là dove? :?
Beh ( vedi risposta a Zanna, ... oddio, no, un MVP :-P ), ora accusatemi di
spam, ma sarebbe solo per la vostra distrazione (quel NG è appena aperto,
diciamo un mesetto), perchè io, transfuga dichiarato (eppur prodigo, forse,
anzi, forsissimo) l'ho scoperto, qui!, da un post di Antonio Cangiano
(
http://makeashorterlink.com/?V202128B5
)
Diciamo che si sta facendo un po' di casino.
Mi piace ancora considerarlo (il casino) costruttivo, ma comincio,
sinceramente, a dubitarne.
Inoltre, vedo, che qualcuno da là è già arrivato qua.
A proposito, qui "casino" si può dire? :-P

 avere poca teoria, ma (anche se poco può contare) molta pratica, sì.
Mi spiace :-(
Non mi pare di aver scritto nulla di ostrogoto.  Condizione per cui si possa
parlare di client/server è che ci siano due processi che si scambiano flussi
di dati
usando un protocollo conosciuto ad entrambi, va meglio?
Siccome stiamo parlando di processi Access non è client server quando usa
il formato mdb. Questo perchè il processo di Access (msaccess.exe) carica
in-process (conosci la distinzione in-process out-process) le dll che
compongono
la Jet-engine.  Un solo processo non è client server. Chiaro no?
SQLServer, cosi come MySQL, è client/Server perchè un processo (il tuo
programma)
comunica con un altro processo o con i thread di una altro processo
(sqlservr.exe) usando un canale di comunicazione che può essere un socket
TCP o una sessione IPX/SPX o un qualcosa di più alto livello come una named
pipe. Normalmente il processo "server" ha dei sottoprocessi
o thread che alloca per ogni sessione di comunicazione (le istanze del tupo
programma).
Il fatto che esista un qualche meccanismo di coordinamento delle richieste
di lettura/scrittura
permette di gestire in un ambiente Client/Server in maniera più efficace le
problematiche di
accesso concorrente rispetto ad una soluzione dove il singolo programma deve
invece farsene
carico.
Facendo un parallelo si tratta quasi della stessa differenza che passa fra
un sistema
multitasking di tipo cooperativo (Windows 3.0) rispetto ad un sistema di
tipo preemtive.
Questo concetto (del processo coordinatore) è stato poi ulteriormente esteso
per gestire non
solo quasi in maniera trasparente per il programmatore il problema della
concorrenza
ma anche il problema della disponibilità e della scalabilità
dell'applicazione.
Tanto che dentro Windows Microsoft ci ha ficcato pure un Transaction Monitor
che si chiama MTS o Component Services.
Riguardo al discorso della pratica e della teoria, ti posso confermare che
servono
entrambe. Ad esempio è' un dato di fatto, sperimentalmente verificabile, che
una base dati
relazionale non normalizzata è causa del 90% dei problemi dei software
gestionali
artigianali.
Saluti.

 ha scritto nel
messaggio news:biidfd$2k6$1...@newsreader2.mclink.it...

GASP!
non sono più convinto di sapere cos'è client-server, ma manco se sono dentro
a matrix o no...
;-)

 A proposito, qui "casino" si può dire? :-P
Certo che si... le parolacce qui si possono dire... le k invece non sono
bene accette chissà perchè! ;-)

 ;-)
Azzarola, non pensavo di sconvolgere le menti :-)
PS. Non serve che quoti tutto il post. La trasmissione
delle informazioni consuma energia.

 "ma che palle!"
Dall'altra si sono moltiplicate o ingrandite ?
giuseppeD

Dai...in fin dei conti QUA' č meglio che LA'...
Un saluto!
Ciao, Luca.

Ragazzi come al solito siete fantastici. Le info passate sono un buon inizio
teorico per incominciare a pensare client/server. Figuratevi che all'inizio
pensavo che fosse necessario utilizzare uno specifica tecnica di
programmazione ma da quanto ho capito necessita solo capirne il concetto e
cioè in particolare la concorrenza tra i processi al di là di questo tutto è
scritto no ? cmq mi sapreste consigliare un testo che approfondisca la
tematica scostandosi da una tecnologia specifica ?
Dani

 vantaggi/svantaggi.
Su questo mi associo.
Senza voler essere "cattivi" mi pare che Dani non abbia ancora le idee
abbastanza chiare...  ;-)
ciao
ugo

 risultati, ma tant'è...)
Intendevo dire, con le evidenti forzature ("tecnicamente" sulla prima e
"realisticamente" sulla seconda), che, qualunque strumento usiamo
(Client/Server o no), dobbiamo (come dicevo nell'ultima) sapere che è la
realtà della multiutenza ad "imporci", prima di tutto, di recepire il
concetto (e quindi risolverne le problematiche conseguenti) di "simultanea
concorrenza". Se non ci è chiaro cosa può accadere in tale situazione, non
sarà certo la presenza di un Client/Server a risolvere il problema, nè
l'assenza dello stesso a crearcene di più.
