Costruire una applicazione in modo corretto

martedì 01 febbraio 2011 - 14.13

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags C# | VB.NET | .NET 4.0 | Visual Studio 2010 | Access (.mdb)

Scorpyo Profilo | Newbie

2 messaggi | Data Invio: mar 1 feb 2011 - 14:13

Ciao a tutti.
Vorrei chiedere il vostro supporto per impostare la struttura base di una applicazione e per alcuni passaggi che mi sono poco chiari.

Premetto che me la cavo abbastanza bene con la sintassi del codice, però malgrado lo studio di diversi manuali, e la ricerca su vari forum,
ancora non mi è chiaro come impostare IN MODO CORRETTO la struttura globale delle applicazioni, sia in termini di utilizzo di classi, moduli, ecc.,
sia riguardo la gestione di alcune funzionalità, come ad esempio la validazione dei dati, la gestione della concorrenza sull'accesso ai dati, e
altre funzioni che andrò a chiarire (e a chedervi) più avanti.

So cos'è una classe, un modulo, e tutto il resto, quindi non vorrei parlare di questo; vorrei invece confrontarmi sulle pratiche migliori per utilizzare questi costrutti e come farlo concretamente e senza errori grossolani di struttura.
In pratica vorrei che la mia applicazione non si limitasse a funzionare e fare quello che deve fare, ma che fosse anche scritta bene!

LA MIA PROPOSTA:
Per fare un buon lavoro sia per me che per chi potrà aver bisogno di queste info, ho pensato di immaginare di costruire in questo post (con il vostro aiuto),
una applicazione elementare, che però rispetti passo passo il corretto approccio allo sviluppo delle funzionalità necessarie.

Proporrei la solita classica applicazione, Clienti-Ordini, che gestisca anche l'accesso di diversi utenti con diversi permessi sull'applicazione e possibilmente sul menù.

Quindi l'applicativo dovrà avere una form iniziale di login, una MainForm MDI con un piccolo menù, e le form per l'inserimento, cancellazione e aggiornamento dei dati anagrafici dei clienti, dei dati sui prodotti, e infine una form dove poter associare ai clienti le ordinazioni dei prodotti.
L'ultima form mi consentirà di aggiungere gli utenti utilizzatori della mia applicazione, con diversi livelli di abilitazione.

Userei un database access, dato che l'applicazione non è molto complessa, e ci saranno cinque tabelle: "AnagraficaClienti", "AnagraficaProdotti",
"Ordini", la tabella "Utenti" e la tabella "Autorizzazioni" per gestire, tra gli utenti, chi può fare cosa;

AnagraficaClienti avrà 3 colonne: ID (chiave primaria e autoincrementante), "NomeCliente" (testo), "Indirizzo" (testo)

AnagraficaProdotti avrà 3 colonne: ID (chiave primaria e autoincrementante), "DescrizioneProdotto"(testo), "QuantitaDisponibile"(Numerico)

Ordini avrà 4 colonne: ID (chiave primaria e autoincrementante), "IdCliente"(Numerico), "IdProdotto"(Numerico), "DataOrdine"(Data)

La tabella "Utenti" avrà 4 colonne: ID (chiave primaria e autoincrementante), "NomeUtente"(testo), Password(Testo), "IdAutorizzazione"(Numerico)

Infine la tabella "Autorizzazioni" avrà 4 colonne: ID (chiave primaria e autoincrementante), "IdUtente", "DescrizioneAbilitazione", "OkInserimento",
"OkAggiornamento", "OkCancellazione"

Vorrei fermarmi a questo punto per potervi chiedere se secondo voi fin qui tutto bene, o se avreste fatto scelte e considerazione diverse, e cominciare con alcune domande, in modo da non spingerci oltre con lo sviluppo senza prima esserci accertati di essere ancora sulla buona strada.

Domanda 1: E' necessario, utile e corretto, creare una classe per ogni entità che dovrò gestire con la mia applicazione?
Se Sì, creeremo 4 classi: Clienti, Prodotti, Ordini, Utenti, ognuna con le sue proprietà.

Per la gestione del menù, immaginando che la nostra applicazione fosse un po' più complessa di come in realtà è, potremmo implementare un binding con una ulteriore tabella nel database (ad esempio una Tab_Menù che contenga le voci del menù e dei sottomenù); come la implementereste? Dovremmo creare una qunta classe "Menu"per tenere sotto controllo la gestione del suddetto menù o lo fareste da codice della mainForm?
Come potremmo gestire lo stato enabled/disabled di alcune voci di menù a seconda dell'utente loggato?

Ultima domanda (per ora): conviene (ed è formalmente più corretto) implementare una classe a se stante per la gestione dello scambio dati con il database?
E' preferibile usare un modulo?
E' meglio implementare le funzioni "Aggiungi", "Aggiorna" "Elimina" sia dei clienti che degli ordini, che degli utenti, direttamente nel codice delle relative form oppure all'interno di una classe/modulo separati, o ancora all'interno delle classi stesse che già rappresentano gli oggetti (intendo ad esempio che ogni classe come "Clienti" possa esporre delle funzioni di Inserimento, Aggiornamento, Cancellazione)

E' un post lungo, che non finisce qui, e un po' ambizioso: definire insieme le procedure formalmente migliori per sviluppare una applicazione.
Vorrei dire che ho letto diverse cose in giro in termini di pattern di sviluppo come MVC o MVVM, studiati per silverlight e WPF e applicabili anche a .forms, ma quello che sto cercando qui con voi non è un pattern standard e indiscutibile, ma piuttosto un approccio semplificato alla gestione dei vari pezzi di codice, e cercare di chiarirsi sul perchè di alcune scelte piuttosto che altre.

Spero che interessi e di avere il vostro feedback. Alla prox. puntata!

Ciao

luigidibiasi Profilo | Guru

1.077 messaggi | Data Invio: mar 1 feb 2011 - 14:32

>Premetto che me la cavo abbastanza bene con la sintassi del codice,
>però malgrado lo studio di diversi manuali, e la ricerca su vari
>forum,
>ancora non mi è chiaro come impostare IN MODO CORRETTO la struttura
>globale delle applicazioni, sia in termini di utilizzo di classi,
>moduli, ecc.,

Hai utilizzato manuali rivolti ai linguaggi di programmazione o rivolti all'ingegneria del software? Ciò che vuoi fare è riconducibile a quell'argomento quindi dovresti focalizzare l'attenzione su quei tipi di testi.

>vorrei invece confrontarmi sulle pratiche
>migliori per utilizzare questi costrutti e come farlo concretamente
>e senza errori grossolani di struttura.
L'utilizzo di questi costrutti, essenzialmente, è legata alla fase di implementazione degli oggetti (che faranno riferimento alle interfacce astratte) che dovrai individuare durante la fase di planning del progetto.

>una applicazione elementare, che però rispetti passo passo il
>corretto approccio allo sviluppo delle funzionalità necessarie.

Come prima, fai riferimento ad un qualsiasi testo di ingegneria del software e scegli li la metodologia che più si avvicina ai tuoi bisogni.

>Proporrei la solita classica applicazione, Clienti-Ordini, che
>gestisca anche l'accesso di diversi utenti con diversi permessi
>sull'applicazione e possibilmente sul menù.
>
>Quindi l'applicativo dovrà avere una form iniziale di login,
>una MainForm MDI con un piccolo menù, e le form per l'inserimento,
>cancellazione e aggiornamento dei dati anagrafici dei clienti,
>dei dati sui prodotti, e infine una form dove poter associare
>ai clienti le ordinazioni dei prodotti.

Ti reindirizzo ad un altro post che tratta l'argomento:
http://www.dotnethell.it/forum/messages.aspx?ThreadID=38034

>Vorrei fermarmi a questo punto per potervi chiedere se secondo
>voi fin qui tutto bene
Dovresti usare un linguaggio di modellazione, evitando di parlare sia di access, sia delle tabelle, sia dei tipi di campi. Dopo che hai schematizzato tutto il funzionamento passi all'implementazione. (Esistono tool automatici che dal progetto astratto ti cacciano fuori l'implementazione nel linguaggio che desideri...) (ibm rational mi sembra)

Chiaramente, anche la linea di sviluppo che stai seguendo tu esiste... (extreme programming mi sembra... quindi scrivi un pezzettino, lo compili e provi se funziona...e via così fino alla fine)

>Domanda 1: E' necessario, utile e corretto, creare una classe
>per ogni entità che dovrò gestire con la mia applicazione?
Si se lavori con linguaggio orientati agli oggetti!

>Se Sì, creeremo 4 classi: Clienti, Prodotti, Ordini, Utenti,
>ognuna con le sue proprietà.
Dovrai poi creare ulteriori classi che gestiscano questi oggetti... classi che sappiano come salvarli, caricarli da dbms etc...

>
>Per la gestione del menù, immaginando che la nostra applicazione
>fosse un po' più complessa di come in realtà è, potremmo implementare
>un binding con una ulteriore tabella nel database (ad esempio
>una Tab_Menù che contenga le voci del menù e dei sottomenù);
>come la implementereste? Dovremmo creare una qunta classe "Menu"per
>tenere sotto controllo la gestione del suddetto menù o lo fareste
>da codice della mainForm?
Qui il discorso si fa' un po' complesso, credo che il menù sia l'ultima cosa che dovrai implementare... così come i permessi.

>Come potremmo gestire lo stato enabled/disabled di alcune voci
>di menù a seconda dell'utente loggato?
Con una matrice di permessi (riga indica l'utente, le colonne i vari permessi)

>
>Ultima domanda (per ora): conviene (ed è formalmente più corretto)
>implementare una classe a se stante per la gestione dello scambio
>dati con il database?
Si, è quasi obbligatorio farlo...

>E' preferibile usare un modulo?
No, sempre classi!!
>E' meglio implementare le funzioni "Aggiungi", "Aggiorna" "Elimina"
>sia dei clienti che degli ordini, che degli utenti, direttamente
>nel codice delle relative form oppure all'interno di una classe/modulo
>separati, o ancora all'interno delle classi stesse che già rappresentano
>gli oggetti (intendo ad esempio che ogni classe come "Clienti"
>possa esporre delle funzioni di Inserimento, Aggiornamento, Cancellazione)
Devi creare classi come ad esempio Anagrafica che espone i metodi SalvaCliente, UpdateCliente, etc... non direttamente negli oggetti...
>
>

>E' un post lungo, che non finisce qui, e un po' ambizioso: definire
>insieme le procedure formalmente migliori per sviluppare una
>applicazione.
Dai un'occhiata al post che ti ho indicato sopra...

>e cercare di chiarirsi sul perchè di alcune scelte piuttosto
>che altre.
I pattern sono 'astrazione della conoscenza', se esistono significa che funzionano nella maggior parte dei casi

>
>Spero che interessi e di avere il vostro feedback. Alla prox.
>puntata!
>
>Ciao
>

Luigi Di Biasi

http://www.dibiasi.it/
http://netsell.dibiasi.it - ecomm software -
http://blogs.dotnethell.it/luigidibiasi/

Scorpyo Profilo | Newbie

2 messaggi | Data Invio: mar 1 feb 2011 - 17:03

Ciao Luigi,

grazie dei tuoi numerosi consigli, ne farò tesoro.
Mi pare che la prima cosa da fare sia leggermi un bel manuale di sw engineering. Spero solo di non trovare qualcosa di troppo vago o troppo tecnico.
In sostanza vorrei solo capire un buon uso delle tecniche di porgrammazione ad oggetti, che per certi versi lasciano tante opzioni alla discrezione del programmatore. Sarebbe bello avere un buon analista alle spalle, pr poter cominciare a capirci davvero qualcosa...

Ti ringrazio per il tempo che hai dedicato al mio post.

Un saluto

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !