[concettuale] Chi conosce un metodo migliore per fare questo?

[dops]

Ciao, arrivo subito al dunque:
Stò facendo una applicazione intranet dove il padrone di un negozio che vende ciclomotori, vuole registrare i suoi clienti e i relativi ciclomotori (o anche solo un ciclomotore) che i clienti comprano da lui. Quindi con l'ausilio di aspx e mysql stò creando questa cosa:
Il padrone del negozio ha appena finito di vendere un ciclomotore ad un cliente e và al computer per registrarlo.
Apre la pagina aspx e si trova davanti un pagina con i campi relativi ai dati del cliente e i campi relativi ai dati del ciclomotore appena venduto.
Inserisce i dati in questi campi e clicca sul suo bel pulsante per registrare il cliente e il ciclomotore. Su questo pulsante c'è un codice che fà questo:
- Una query sql (select) dove controlla se nel database già esiste un utente con il nome e cognome appena digitato. Se esiste, viene inviato un avviso di utente esistente e vengono visualizzati i dati del cliente. Il padrone del negozio a questo punto controlla che non sia una omonimia, se non lo è (se quindi è un cliente che ha solo il nome e cognome uguale a quelli di un altro) può scegliere di continuare ad inserire i dati immessi, altrimenti può scegliere di inserire solo i dati del ciclomotore ed associare questo ciclomotore a questo utente che ha già acquistato altre volte.

- Se quindi il cliente non esiste ancora nel database, si prosegue con il codice e si inseriscono i record nel database che contiene due tabelle: "Ciclomotori" - "Clienti".
Per fare una relazione tra queste tabelle è stato immesso un campo "cliente" nella tabella ciclomotori, che è stato collegato con il campo "ID" della tabella "Clienti". Quindi il campo Ciclomotori.Cliente è una copia del campo Clienti.ID.

Quello che vi chiedo quindi è questo:
La struttura logica di inserimento del nuovo cliente e ciclomotore (cliente che quindi non esiste nel database) è questa:

- Inserimento record del cliente.
- Recupero (select) dell'ID del record appena inserito
- Inserimento del Ciclomotore dove nel campo Ciclomotore.Cliente verrà inserito l'ID appena recuperato.
E' un ragionamento giusto? ma molto + importante.. esiste un metodo migliore?

Ciao

[riccardone]

Originariamente inviato da dops ...il padrone di un negozio che vende ciclomotori, vuole registrare i suoi clienti e i relativi ciclomotori (o anche solo un ciclomotore) che i clienti comprano da lui.

Quindi in questa specie di caso d'uso che hai descritto ci sono due entita'
cliente e ciclomotore

Il padrone del negozio ha appena finito di vendere un ciclomotore ad un cliente e và al computer per registrarlo.

Per registrare cosa? Ci sono 3 possibili cose che potrebbe registrare nella sua azione ma non si capisce a quale delle tre ti riferisci (il negozio? il cliente? il ciclomotore?...) da questa tua frase non si capisce un granche' e mi sembra non ci faccia molta chiarezza il resto.
Te lo dico per stimolarti ad effettuare una analisi migliore prima di iniziare lo sviluppo effettivo di una qualsiasi applicazione (piccola o grande che sia).
La strada da seguire potrebbe essere quella di scrivere dei semplici casi d'uso (use case). Identificare le entita' presenti nei casi d'uso e definirne meglio i contorni (attributi) e le azioni (metodi e funzioni).
Passare quindi a creare una libreria di classi che sara' il livello di business logic della nostra applicazione e che conterra' ad esempio la classe cliente con i suoi attributi e la classe ciclomotore con i suoi attributi. Aggiungere poi ad esempio alla classe cliente i metodi nuovo modifica elimina elencoclienti trovacliente e lo stesso per la classe ciclomotore. Il codice per collegarti direttamente al db puoi metterlo dentro questi metodi oppure se ti interessa passare da un db all'altro piu' facilmente puoi creare un altro livello di accesso ai dati mettendo in un altra libreria il codice che si interfaccia direttamente con il db (mysql, sqlserver, access ecc.). Alla fine ti diverti a creare l'interfaccia utente.
Quindi l'applicativo dovrebbe avere
- un progetto A che interagisce con l'utente
- un progetto B che contiene la business logic
- un progetto C che gestisce i collegamenti col database
Il progetto A fara' riferimento al progetto B. Il progetto B fara' riferimento al progetto C.
Questo approccio, rende piu' gestibile il tuo codice, piu' portabile su diversi db e permette un miglior sviluppo anche in vista di aggiunte future. Un approccio di questo tipo anche se si tratta di piccoli progetti, ti aiuta ad entrare nella giusta logica di programmazione se sviluppi da solo i tuoi progetti e diventa indispensabile se lavori in team. Non e' comunque qualcosa la cui bonta' si impara da un post su un newsgroup ma necessita si studio ed esperienza.

[dops]

Originariamente inviato da riccardone
Quindi in questa specie di caso d'uso che hai descritto ci sono due entita'
cliente e ciclomotore

Per registrare cosa? Ci sono 3 possibili cose che potrebbe registrare nella sua azione ma non si capisce a quale delle tre ti riferisci (il negozio? il cliente? il ciclomotore?...) da questa tua frase non si capisce un granche' e mi sembra non ci faccia molta chiarezza il resto.
Te lo dico per stimolarti ad effettuare una analisi migliore prima di iniziare lo sviluppo effettivo di una qualsiasi applicazione (piccola o grande che sia).
La strada da seguire potrebbe essere quella di scrivere dei semplici casi d'uso (use case). Identificare le entita' presenti nei casi d'uso e definirne meglio i contorni (attributi) e le azioni (metodi e funzioni).
Passare quindi a creare una libreria di classi che sara' il livello di business logic della nostra applicazione e che conterra' ad esempio la classe cliente con i suoi attributi e la classe ciclomotore con i suoi attributi. Aggiungere poi ad esempio alla classe cliente i metodi nuovo modifica elimina elencoclienti trovacliente e lo stesso per la classe ciclomotore. Il codice per collegarti direttamente al db puoi metterlo dentro questi metodi oppure se ti interessa passare da un db all'altro piu' facilmente puoi creare un altro livello di accesso ai dati mettendo in un altra libreria il codice che si interfaccia direttamente con il db (mysql, sqlserver, access ecc.). Alla fine ti diverti a creare l'interfaccia utente.
Quindi l'applicativo dovrebbe avere
- un progetto A che interagisce con l'utente
- un progetto B che contiene la business logic
- un progetto C che gestisce i collegamenti col database
Il progetto A fara' riferimento al progetto B. Il progetto B fara' riferimento al progetto C.
Questo approccio, rende piu' gestibile il tuo codice, piu' portabile su diversi db e permette un miglior sviluppo anche in vista di aggiunte future. Un approccio di questo tipo anche se si tratta di piccoli progetti, ti aiuta ad entrare nella giusta logica di programmazione se sviluppi da solo i tuoi progetti e diventa indispensabile se lavori in team. Non e' comunque qualcosa la cui bonta' si impara da un post su un newsgroup ma necessita si studio ed esperienza.

Sei stato un pò cattivo, penso di essere stato abbastanza chiaro, non solo perchè parlo in italiano (un buon italiano) ma anche perchè non mi pare che alcun periodo abbia preso un'altra strada.
Non ho capito perchè sei stato così duro ma ti ringrazio lo stesso..
Non pretendo di imparare da un post e non credo di seguire i tuoi consigli, che potrebbero essere anche sbagliati. Ma ti ripeto: Grazie. Almeno ho conosciuto un'altra realtà.. magari se avessi risposto con un atteggiamento meno critico, forse anche meno professionale, la cosa sarebbe stato sicuramente più gradita.
Ciao

[dops]

opss.. ho dimenticato:
Sinceramente.. ma tu (però sinceramente) crei delle classi a parte con metodi e proprietà per ogni piccola applicazione che fai?
E dai..

[riccardone]

Originariamente inviato da dops
Sei stato un pò cattivo

come non detto

[DeBe99]

io l'unica cosa che farei e cercare di non obbligare ad inserire i dati del cliente per poi verificare se esiste
La farei composta da due pagine principali, anagrafica clienti e ciclomotori, e ognuna dovrebbe avere funzionalità per inserimento/ricerca/modifica e cancellazione. Ovviamente l'anagrafica ciclomotori dovrà avere un campo per immettere il codice del cliente (magari con una pop-up che fa la ricerca tramite l'anagrafica clienti). l'anagrafica clienti dovrebbe avere due link, uno per cercare tutti i ciclomotori di quel cliente (precompilando i campi di ricerca della stessa anagrafica ciclomotori) e d uno per aggiungne uno nuovo (precompilando il odice cliente).
In questo modo rimane molto slegata e i consente diverse strade per fare la stessa cosa, quando vendi un ciclomotore potrai decidere se iniziare a creare il cliente, se creare il ciclomotore perchè il cliente sai che c'è già o se partire dalla ricerca per cliente.

non so se mi sono capito

[DeBe99]

Originariamente inviato da dops
opss.. ho dimenticato:
Sinceramente.. ma tu (però sinceramente) crei delle classi a parte con metodi e proprietà per ogni piccola applicazione che fai?
E dai..

[pignolo mode]adesso si perchè .NET lavora solo per classi, non ci sono più i moduli [/pignolo mode]

[dops]

Originariamente inviato da DeBe99
io l'unica cosa che farei e cercare di non obbligare ad inserire i dati del cliente per poi verificare se esiste
La farei composta da due pagine principali, anagrafica clienti e ciclomotori, e ognuna dovrebbe avere funzionalità per inserimento/ricerca/modifica e cancellazione. Ovviamente l'anagrafica ciclomotori dovrà avere un campo per immettere il codice del cliente (magari con una pop-up che fa la ricerca tramite l'anagrafica clienti). l'anagrafica clienti dovrebbe avere due link, uno per cercare tutti i ciclomotori di quel cliente (precompilando i campi di ricerca della stessa anagrafica ciclomotori) e d uno per aggiungne uno nuovo (precompilando il odice cliente).
In questo modo rimane molto slegata e i consente diverse strade per fare la stessa cosa, quando vendi un ciclomotore potrai decidere se iniziare a creare il cliente, se creare il ciclomotore perchè il cliente sai che c'è già o se partire dalla ricerca per cliente.

non so se mi sono capito

Ciao. La funzione di riecerca è già in progetto. Io credo, ma forse mi sbaglio ed è proprio questo il motivo per cui ho scritto nel forum, che la struttura logica o concettuale dell'applicazione, l'abbia calibrata bene (classi a parte). Voglio dire:
L'utente (il padrone del negozio) che certo non ricorderà se il cliente che ha appena comperato un ciclomotore ne ha già comperato uno 2 anni fà, si trova di fronte ad una pagina di data entry dove già graficamente gli viene proposta una struttura che gli dà almeno "l'illusione" di tenere le due entità (cliente - ciclomotore) sotto controllo. Come dicevo lui non sà se il cliente ha già comperato e quindi inzia ad inserire i dati. Il programma controlla se esiste o meno e gli propone una alternativa (visualizzando tutti i dati del presunto cliente esistente. Potrebbe essere un caso di omonimia e quindi l'utente decide di proseguire con l'inserimento del nuovo cliente>ciclomotore, oppure continua con l'inserimento del nuovo cliente..
Vi faccio vedere uno screen shot di come l'applicazione si presenta alla prima apertura (l'home page):

[DeBe99]

dovresti però stare molto attento ai validatori. Se la residenza e obbligatoria ad esempio, diventa abbastanza scomodo doverla inserire ogni volta anche se esiste già il record (il cliente potrebbe anche essere un piccolo rivenditore che compra spesso in quel negozio). Potresti aggiungere un pulsante di fianco a nome cognome che verifica se il nominativo esiste già (questo pulsante non dovrebbe usare la validazione) e che riempe i dati restanti.

[dops]

Originariamente inviato da DeBe99
dovresti però stare molto attento ai validatori. Se la residenza e obbligatoria ad esempio, diventa abbastanza scomodo doverla inserire ogni volta anche se esiste già il record (il cliente potrebbe anche essere un piccolo rivenditore che compra spesso in quel negozio). Potresti aggiungere un pulsante di fianco a nome cognome che verifica se il nominativo esiste già (questo pulsante non dovrebbe usare la validazione) e che riempe i dati restanti.

perchè la residenza può essere lunga da scrivere intendi?
eh.. questa è una bella soluzione.. non ci avevo pensato grazie
cmq i validatori ci sono..