04/10/2024 - GrandfatherCoder ha scritto:
Può essere una demo,ma anche no.
Pubblicamente non parlo dei miei progetti.
Non c'è bisogno di citare dati specifici su clienti e/o progetti che siano identificabili: basta stare sul generico.
Stiamo parlando di una applicazione Web con un carrello: senza fare riferimento a persone, cose o aziende, non mi pare che si tratti di un brevetto internazionale. :)
04/10/2024 - GrandfatherCoder ha scritto:
Purtroppo ognuno ha una sua visione sullo sviluppo software,razionalmente dettata da situazioni,conoscenze ed esperienze.
Meno razionalmente dai punti di vista personali.
Certo, però quando se ne discute online, generalmente si cerca di motivare facendo riferimento a qualcosa di specifico: indicare delle opinioni giustificandole col fatto che tutti hanno diritto ad averle, non fa capire perché si hanno certe opinioni e qual è il criterio o il ragionamento dietro. Se poi si tratta di scegliere delle soluzioni, a maggior ragione.
04/10/2024 - GrandfatherCoder ha scritto:
Perchè per il carrello ho scelto un oggetto TFDMemTable e non un array di records?
TFDMemTable è un bel coltellino svizzero con parecchi metodi e proprietà utili e che mi tornano utili al momento opportuno.
Questo è un esempio perfetto per quello che dicevo. “Un bel coltellino svizzero con metodi e proprietà utili”… ma perché, un array non ce li ha?
La MemTable è un DataSet: si tratta di una tabella simil-DB che sta in memoria e che contiene record e colonne, assegnati a un tipo, con metodi e proprietà per spostarsi in avanti, indietro, andare all'inizio, alla fine, inserire, modificare, ecc.
Se dovessi fare queste operazioni, magari con il coinvolgimento di una interfaccia utente, di certo il DataSet ti consente di farlo con pochi clic e senza scrivere troppo codice.
Se dovessi memorizzare dati generici relativi a un carrello e manipolarli tramite codice, MAI sceglierei un DataSet, per tanti buoni motivi:
- per accedere a un elemento specifico devo “navigare” il DataSet e non posso accedere direttamente tramite un indice (di solito);
- la gestione del DataSet in sé come principio di funzionamento ha un suo overhead che rallenta l'esecuzione, se non serve;
- i campi sono indirizzati tramite il relativo nome, come stringhe, quindi non si può beneficiare del completamento del codice e un eventuale refactoring potrebbe esporre a errori rilevabili solo a runtime;
- occupano più spazio in memoria, oltre a essere più lenti come da punto 2);
- rappresentano bene solo elenchi “flat” di record e non possono rappresentare strutture dati più complesse (es. alberi, dizionari, ecc.).
Però questa è una disamina con cui si sceglie se usare o meno un DataSet (quale è il MemTable), valutando vantaggi e svantaggi.
Dire “massì, uso il DataSet perché ha dei metodi utili”, non dice sostanzialmente nulla, o suggerisce che è la struttura dati da usare sempre per via di questa caratteristica da “coltellino svizzero”, quando ogni cosa in Delphi (e non solo) è un coltellino svizzero, però dipende da qual è la scatola da aprire o da tagliare. :)