[vb.net] come posso migliorare questa funzione?

[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.