[ASP.NET 2.0] Mi serve un consiglio...

[Giobby]

Salve a tutti.
Sto cercando di imparare un po di ASP.NET 2.0 e non so bene come muovermi in fatto di comunicazione con il DB.
Qual'è il modo migliore per gestire connessioni ed accesso ai dati ?
Attualmente ho una solution che contiene un progetto con le pagine, una DLL con i command di select, insert, update e delete, e un web service che punta alla DLL e con i metodi restituise alla pagina un eventuale dataset in caso di select o semplicemente un esito del command di update, insert o delete.

Non so se questo è il modo giusto di gestire l'applicazione, perchè ho incluso nella pagina del mio progetto una griglia (griglia con l'elenco dei clienti per fare un esempio) e volevo fare il paging. Ma non posso visto la riempio tramite il dataset restituito dal web services. Infatti dovrei usare l'oggetto SqlDataSource.
Quindi sono un po perplesso sulla strada che sto seguendo.

Mi sapete consigliare il metodo giusto ?
Grazie 1000

[gugoXX]

La strada e' quella consigliata per progetti ASP.net 2.0, di qualche hanno fa.
Non usare il SqlDataSource. Usa l'oggetto ObjectDataSource, e vi mapperai direttamente sopra le funzioni del WebService.
In questo modo la DLL potra' essere utilizzata sia per le esigenze del client, sia per le esigenze del server.
Un unico punto di accesso per entrambi.

[Giobby]

Mhhh. Scusa la mia profonda lacuna...
Ho trascinato nella pagina con la griglia clienti l'oggetto.
Se metto la spunta su show only data component non vedo nulla nel combo.
Quindi l'ho lasciato senza spunta ed ho puntato all'ASMX del web service che contiene i metodi per il fill della griglia.

Così intendevi ?

[Giobby]

Funziona.

Ma quindi è giusta la struttura che ho fatto ?

[gugoXX]

Direi di si'.
Il SQLDataSource non si puo' usare agevolmente in ambiente WEB, perche' nella sua implementazione di base richiede una connectionstring. In pratica si lavora a 2 livelli, tra WebBrowser del Client e il DBServer.
A parte che e' un'archiettura bruttina, la maggior parte delle volte addirittura il DBServer non e' giustamente accedibile dai client.
Utilizzando l'ObjectDataSource invece si vanno a chiamare direttamente le funzioni del WebService.

Ora, che funzioni subito senza dover fare nulla mi sembra strano. Almeno una schermata in cui ti chiede il nome della funzione di Select (del WebService), e se servono anche la Update, Delete, Insert, avrebbe dovuto comparire.

[Giobby]

In effetti funziona bene solo la select e la delete.
Sto facendo un po di prove perchè prima all'evento dei link di Edit e Delete avevo dentro del mio codice. Quindi sto cercando di capire come gestire il tutto. Ti faccio sapere.
Grazie 1000 sei molto prezioso.

[nuovoUtente86]

Originariamente inviato da gugoXX

Direi di si'.
Il SQLDataSource non si puo' usare agevolmente in ambiente WEB, perche' nella sua implementazione di base richiede una connectionstring. In pratica si lavora a 2 livelli, tra WebBrowser del Client e il DBServer.
A parte che e' un'archiettura bruttina, la maggior parte delle volte addirittura il DBServer non e' giustamente accedibile dai client.
Utilizzando l'ObjectDataSource invece si vanno a chiamare direttamente le funzioni del WebService.

Ora, che funzioni subito senza dover fare nulla mi sembra strano. Almeno una schermata in cui ti chiede il nome della funzione di Select (del WebService), e se servono anche la Update, Delete, Insert, avrebbe dovuto comparire.

Non ho ben capito cosa vuoi dire esattamente: personalmente utilizzo SQLDataSource nelle pagine web senza alcun problema in quanto il controllo agisce lato server e quindi il client non ha nessuna interezione con il DB.Il tuo esempio non è riferito forse ad una pagine web ma ad un web service inteso come pubblicazione di un servizio?

[gugoXX]

Si', esatto, l'ObjectDataSource generico puo' essere utilizzato congiuntamente ad un WebService, in modo da realizzare il dialogo 3 livelli classico.
Il SqlDataSource personalmente non l'ho mai usato, per questioni di generalizzazione. Dato che alla fine quello che si espone e' quasi sempre modellabile con il SQL standard, preferiamo non vincolarci ad un Database specifico.
Inoltre lo scrivere le proprie query a mano ha i suoi vantaggi.
Nella scrittura di un WebService proprio in questo periodo sto provando ad evitare la connessione al database classica dal webservice al database, e sto provando ad utilizzare LINQ.
Devo dire che sono decisamente soddisfatto.

[nuovoUtente86]

Originariamente inviato da gugoXX

Si', esatto, l'ObjectDataSource generico puo' essere utilizzato congiuntamente ad un WebService, in modo da realizzare il dialogo 3 livelli classico.
Il SqlDataSource personalmente non l'ho mai usato, per questioni di generalizzazione. Dato che alla fine quello che si espone e' quasi sempre modellabile con il SQL standard, preferiamo non vincolarci ad un Database specifico.
Inoltre lo scrivere le proprie query a mano ha i suoi vantaggi.
Nella scrittura di un WebService proprio in questo periodo sto provando ad evitare la connessione al database classica dal webservice al database, e sto provando ad utilizzare LINQ.
Devo dire che sono decisamente soddisfatto.

Nei pochi webservice che ho fatto in java ho sempre posto il servizio esposto come tramite tra client e DB, facendo lavorare il service sul DB.Se ho intuito invece fai interagire client e DB?

[gugoXX]

No, penso sia la stessa cosa. Il client chiama il web-service, il quale legge i dati, li formatta in JSON e li rispedisce al client, in modo asincrono.
Il tutto e' stato incapsulato nella tecnologia AJAX.

ObjectDataSource e' un wrapper delle chiamate al Web-Service.
I WebDataSource sono degli oggetti che forniscono sempre la stessa interfaccia verso i controlli Web ASP.net, creati per poter slegare appunto i controlli dalla implementazione dal servizio che fornisce i dati.

Con un SqlDataSource se non ricordo male non e' necessario costruire un WebService, il tutto e' pronto all'uso, interfacciandosi ad un SqlServer.
ObjectDataSource invece e' il wrapper per un WebService Generico, che deve pero' implementare almeno alcuni metodi standard per potervi chiacchierare insieme.

In pratica e' la stessa cosa che chiamare direttamente un WebService da qualche funzione Javascript della pagina client, ma e' tutto incapsulato e controllato in fase di compilazione (e testabile senza fare salti mortali)
LINQ ha esteso il controllo in fase di compilazione anche verso il Database. Dove prima invece c'erano solo stringhe di comandi tipo "SELECT qualcosa FROM tabella..." ora ci potranno essere vere e proprie istruzioni C#.

[nuovoUtente86]

Originariamente inviato da gugoXX

Direi di si'.
Il SQLDataSource non si puo' usare agevolmente in ambiente WEB, perche' nella sua implementazione di base richiede una connectionstring. In pratica si lavora a 2 livelli, tra WebBrowser del Client e il DBServer.
A parte che e' un'archiettura bruttina, la maggior parte delle volte addirittura il DBServer non e' giustamente accedibile dai client.
Utilizzando l'ObjectDataSource invece si vanno a chiamare direttamente le funzioni del WebService.

era questo che mi aveva fatto pensare al fatto che bypassassi il livello controllo in qualche modo, perchè parli di 2 livelli tra sqldatasource e DB ma il controllo,almeno per come l' ho sempre utilizzato io lato server ed è giusto che il DB sia nascosto al client.

[Giobby]

Non ci sto capendo nulla.
Ma allora com'è meglio agire?
Brevemente...
Devo fare un gestionale con DB SQL2005.
Attualmente ho una dll per i command al DB. La connection string la prendo tramite un'altra dll che legge da file ini i settaggi del DB.
La Dll dei command viene referenziata in un WebService che a sua volta viene referenziato nel progetto con le pagine web.

Nella mia pagina web devo popolare una griglia ed ho usato l'objectdatasource che punta ai metodi del webService.
A sto punto mi chiedo...ma è realmente questo l'iter standard da seguire per un progetto web tipo il mio ?
Se uso l'SQLdatasource questi 3 livelli non ci sono più, perchè faccio tutto nella pagina. Mhhh!

[gugoXX]

Secondo me si'.
Seguendo il tuo approccio potrai anche sviluppare un componente WinForm, una vera applicazione, condividendo lo stesso WebService.
Ma il WebService l'hai scritto tu?

[Giobby]

Si l'ho scritto io. Perchè? Non mi sembra una cosa tanto strana. Alla fine è solo una subroutine con scritto webmethod in testa.
Per i WinForm non uso i WebService.

Ma dimmi un'altra cosa.
Con VS2005 faccio un po fatica a raccapezzarmi con i WebService. Mi spiego meglio.
Nel mio progetto ho fatto le WebReference ai WebService.
Sia il WebService che il progetto con le pagine web nelle properti di default usano il visual studio development server, ovvero gli viene assegnata una porta che può essere statica o dinamica.
Usare il default è comodo perchè non devo creare virtual directory. Ma quando riavvio il PC le WebReference devo rifarle perchè la porta cambia.
Mettendo la porta statica sono costretto (prima di lanciare il progetto delle pagine) a lanciare in debug il WebService per aprire la porta.
Allora ieri cosa ho fatto (visto che sto metodo non mi piace)...ho creato le virtual directory ed ho impostato le proprietà su IIS Server, in modo da usare http://localhost/mioprogetto/etc.
Ok, le Web reference le fa tranquillamente, ma quando lancio la pagina che dovrebbe leggere il Web Method del Web Service mi da accesso negato.
Perchè?

[gugoXX]

Originariamente inviato da Giobby

Si l'ho scritto io. Perchè? Non mi sembra una cosa tanto strana. Alla fine è solo una subroutine con scritto webmethod in testa.
Per i WinForm non uso i WebService.

Perfetto. Se per caso il tuo progetto avesse anche una parte winform che accede al database come un'utility di amministrazione o una vera e propria versione "programma" del sito, allora ti consigliavo di usare anche qui lo stesso webservice, per accentrare la logica di connessione e condividere le query (e la sicurezza)
Anche eventuali serivizi Windows li farei passare attraverso lo stesso WebService. Azioni tipiche da servizio sono magari "La pulizia deigli utenti vecchi", oppure "inseriemnto periodico di dati letti da un altro database", etc.

Ma dimmi un'altra cosa.
Con VS2005 faccio un po fatica a raccapezzarmi con i WebService. Mi spiego meglio.
Nel mio progetto ho fatto le WebReference ai WebService.
Sia il WebService che il progetto con le pagine web nelle properti di default usano il visual studio development server, ovvero gli viene assegnata una porta che può essere statica o dinamica.
Usare il default è comodo perchè non devo creare virtual directory. Ma quando riavvio il PC le WebReference devo rifarle perchè la porta cambia.
Mettendo la porta statica sono costretto (prima di lanciare il progetto delle pagine) a lanciare in debug il WebService per aprire la porta.

Puo' capitare, ma non dovrebbe capitare cosi' spesso. Quando capitasse sarebbe sufficiente aggiornare la WebReference nei progetti consumatori, nel tuo caso il WebSite. (Destro -> Update Web Reference)
Per quanto riguarda il debug, e' sufficiente lanciare l'esecuzione in modalita' multiprogetto, e scegliere di far partire contemporaneamente il WebSite e il WebServer. In questo modo dovresti risolvere i tuoi problemi (Destro sulla soluzione -> StartUpProject -> MultipleStartup)

Allora ieri cosa ho fatto (visto che sto metodo non mi piace)...ho creato le virtual directory ed ho impostato le proprietà su IIS Server, in modo da usare http://localhost/mioprogetto/etc.
Ok, le Web reference le fa tranquillamente, ma quando lancio la pagina che dovrebbe leggere il Web Method del Web Service mi da accesso negato.
Perchè?

Strano, penso sia un settaggio di IIS. Anche perche' e' il metodo normale di pubblicazione. Se non funziona non funzionera'.
Prova anche a giocare con il web.config del progetto WebService. Se non c'e' aggiungilo, e cerca in giro i parametri giusti.
Uno critico dovrebbe essere "Enable Remote Debug", che dovrebbe servirti per poter debuggare usando l'istanza remota (stai passando attraverso IIS, quindi e' considerata remota anche se su localhost)

[Giobby]

Grazie, del multiple startup non lo sapevo (quante differenze con il 2002).
Per i WebService invece ho riscontrato che non è una regola.
Ho 3 WebServices attualmente.
Uno per un treeview del masterpage con le pagine richiamabili, uno per il ciclo attivo (clienti etc.) e uno per ciclo passivo (fornitori etc.).
Sono questi ultimi 2 che non vanno.
Ma i WebConfig ci sono in tutti e 3 però in nessuno di questi c'è la voce che hai detto. Che non sia un settaggio di IIS per questi ultimi 2 WebServices ?

Se lancio il WebService per i fatti suoi funziona. Boh!

[Giobby]

UP