[vb.net] come posso migliorare questa funzione?

[optime]

certo che in nessun libro troverai esattamente che ti dicano come fare il TUO servizio

credo che tu stia sbagliando approccio: servizi generici fanno cose generiche, servizi custom fanno cose custom

quindi la domanda è: che devi fare?

[Kahm]

certo che in nessun libro troverai esattamente che ti dicano come fare il TUO servizio

credo che tu stia sbagliando approccio: servizi generici fanno cose generiche, servizi custom fanno cose custom

quindi la domanda è: che devi fare?

Ok ok custom


Come detto prima ero dubbioso
Grazie a tutti

[alka]

Il servizio deve essere generico vero?

Di quale servizio si parla? Cosa fa? Cosa si intende per "generico"?

Se identifichiamo con "servizio" un qualunque Web Service, la sua "genericità" dipende da cosa deve fare il servizio: se si tratta del WS di un mio sistema verticalizzato su un cliente, accetterà i dati previsti dal dominio di business dell'applicazione; se si tratta di un WS che va sul sito INPS per i cittadini italiani, sarà ancora diverso, mentre se è una API ad accesso universale, ci saranno altri crismi, ma tutto quanto dipende dai requisiti: che servizio è, cosa deve fare, a chi è rivolto, che dati deve utilizzare, a che scopo, con quali restrizioni...

Ma se io invio tutto il form al servizio esso allora pu� essere usato solo da me.

Quello non dipende da quanti dati invii, ma da come il servizio è stato strutturato.
Il servizio lo può usare chiunque abbia la possibilità di invocarlo. Non è una questione dei campi che mandi intesi come quantità o nomenclatura, è una questione legata a come il sistema è stato progettato in termini di business, di analisi, di processo, di funzionamento.

Una cosa del genere poi non penso di averla mai letta in nessun libro che il servizio su deve preoccupare di associare a ciasxuna property ol valore dei campi che ovviamente possono essere diversi in ogni pagina che usa il servizio.

Onestamente, non riesco nemmeno a dare un significato a questa affermazione, anche rileggendola.
L'associazione di property a campi è una questione meramente tecnica: non c'entra nulla con le finalità e le modalità di impiego di un servizio.

Rcco perch� chiedevo anche voi cosa usate di preciso e come fate

Continuo a non capire.

[Kahm]

Di .
Continuo a non capire.

Nel mio servizio che sto scrivendo accetta un foem al cui interno ci devono essere i campi:txtNome, txtCognome,CBBcitta
Basta un form che viene da un'altra parte con un solo nome campo diverso, ed ecco che non funziona piu

[optime]

Nel mio servizio che sto scrivendo accetta un foem al cui interno ci devono essere i campi:txtNome, txtCognome,CBBcitta
Basta un form che viene da un'altra parte con un solo nome campo diverso, ed ecco che non funziona piu

Kahm, se il servizio è custom le chiamate non possono arrivare da dovunque: se il servizio traduce la form X in un oggetto Y, la form può solo essere conformata secondo quello che hai scritto tu --> se al servizio arriva una form Z, sarà scartata

Se vuoi allargare il servizio anche alle form Z, dovrai scrivere delle logiche aggiuntive, e chi ti chiama dovrà anche presentarsi, dicendo "sono la form X" piuttosto che "sono la form Z"

Qualunque servizio ha le sue regole, che debbono essere rispettate dal chiamante

Adesso tu stai affrontando il tema con delle form, ma se in input il servizio prevedesse un xml, un json, o anche semplici parametri passati via querystring, chi chiama DEVE seguire le regole

se fai un servizio "somma" da chiamare con .../somma?add1=10&add2=20 cosa succede se lo chiamo in questo modo .../somma?par1=10&par2=20 ?

[alka]

Nel mio servizio che sto scrivendo accetta un foem al cui interno ci devono essere i campi:txtNome, txtCognome,CBBcitta
Basta un form che viene da un'altra parte con un solo nome campo diverso, ed ecco che non funziona piu

In linea di principio, il tuo servizio non deve "accettare un form", ma accettare dei dati, ovvero nome, cognome, città, ecc.

Detto questo, non c'è motivo per cui i parametri dovrebbero fare riferimento a un form o a un controllo, tipo txtNome, perché tu non invii il controllo o il form, ma invii i dati.

Questo non è qualcosa che abbia a che fare con la genericità, ma con una correttezza formale che prevede di chiamare nel modo giusto le cose, usando dei nomi che facciano capire quello che viene veicolato.

Il fatto che altri possano richiamare il servizio è una questione non correlata: basta che sappiano che il nome va inviato con il nome di campo "txtNome".

Al massimo, vedendo i nomi dei campi, quello che potrebbero fare è porsi le stesse domande e contestazioni che sto facendo io, e di conseguenza porsi svariati dubbi sulle motivazioni di una scelta del genere e/o sulla bontà della architettura in generale.

[optime]

In linea di principio, il tuo servizio non deve "accettare un form", ma accettare dei dati, ovvero nome, cognome, città, ecc.

ni. Se chiamante e chiamato si accordano per veicolare un qualunque oggetto di qualunque natura, direi che è lecito e sono fatti loro

IMHO

[alka]

ni. Se chiamante e chiamato si accordano per veicolare un qualunque oggetto di qualunque natura, direi che è lecito e sono fatti loro

IMHO

Sì, concordo: è per quello che ho specificato in linea di principio.

Non dico che non sia possibile farlo.
Ciò che dico è che, in linea di principio, non andrebbe fatto, non si fa (non trovi in giro servizi realizzati in questo modo), e non lo farei.

Sul fatto che sia possibile, certo: potrei anche chiamare "Ordini" una API che gestisce "Fatture" e non smetterebbe di funzionare, perché informaticamente parlando la nomenclatura non ha effetti sul comportamento, ma c'è anche l'aspetto progettuale da tenere in considerazione.

Quindi più che "ni", la risposta è "sì" per la fattibilità, "decisamente no" per la scelta.

[Genas]

Il servizio deve essere generico vero?
Ma se io invio tutto il form al servizio esso allora pu� essere usato solo da me.
Una cosa del genere poi non penso di averla mai letta in nessun libro che il servizio su deve preoccupare di associare a ciasxuna property ol valore dei campi che ovviamente possono essere diversi in ogni pagina che usa il servizio.

Rcco perch� chiedevo anche voi cosa usate di preciso e come fate

Il servizio dovrebbe essere generico, ma se invio tutto il form al servizio, esso può essere utilizzato solo da me, quindi volevo sapere cosa usate voi e come gestite l'associazione dei valori dei campi per ogni pagina che utilizza il servizio.

[alka]

Il servizio dovrebbe essere generico, ma se invio tutto il form al servizio, esso può essere utilizzato solo da me, quindi volevo sapere cosa usate voi e come gestite l'associazione dei valori dei campi per ogni pagina che utilizza il servizio.

Non capisco perché intervenire in una discussione riprendendo la richiesta di un altro utente orientando su un altro percorso la domanda posta.