C# + SqlServer, vostre opinioni.

[the.ales]

Innanzitutto un buongiorno a tutto il foro.
Chiedo scusa se ho sbagliato sezione, ma ho letto "Visual Basic e .net framework", e la mia domanda riguarda il C#, quindi ipotizzo che di .net si parla! xD ma comunque...
Sono nuovo, mi chiamo Alessio e sono un ragazzo di 23 anni, che dopo esser stato lontano dalla programmazione (che idiota che sono stato), per 4 anni e ora mi ritrovo a dover scrivere un programma (da zero), per la gestione del flusso postale.

Premettiamo che:
-> A scuola ho studiato C++ (nemmeno visual), e finita la scuola l'ho lasciato lì.
-> Da meno di mezzo mese ho comprato 2 manuali di C#(apogeo)
-> Usai Mysql a scuola, ma sinceramente "chi se lo ricorda..."

Dopo queste belle premesse vi pongo il mio problema!
Questo programma dovrà gestire la posta, quindi avrò diversi db (clienti, raccomandate, plichi, stradari, postini, etc etc), e sarà una cosa adottato in diversi comuni (c'è già un vecchio programma, però dobbiamo cambiarlo).
Da quanto ho capito dal vecchio programma non è altro che la progettazione di diversi form, diversi database, e non è altro che "insert", "delete", "update" e "select", ovviamente a seconda di che operazione uno fà.
Per il database uso SqlServer 2012, e come ambito di sviluppo uso Visual Studio 2010.
Le mie domande sono queste:

-> Voi come vi comportereste? Cosa fareste al mio posto? Onestamente ho paura che la cosa sia abbastanza più grande di me, però cavolo, perchè non ci dovrei riuscire?
-> Sono nuovo di ambienti "Visual", però sembra abbastanza semplice da capire...qualche buona guida per imparare le basi?

Scusate in anticipo per le numerose domande che vi farò...
Grazie mille in anticipo per le risposte!

[tas]

Mi sembra impegnativo come "primo progetto", in ogni caso provo a darti qualche dritta.

Database: SQL Server è senz'altro quello più integrato con Visual Studio, ma non è ovviamente obbligatorio e puoi orientarti anche verso altri db.

Linguaggio: se conosci C++ non avrai difficoltà con C#, secondo me però la cosa più impegnativa sarà quella di conoscere abbastanza bene il framework .NET, che è molto ampio.

Visto il trend attuale, credo sarebbe "furbo" scrivere un'applicazione suddivisa in "layer", almeno tre e cioè:

• data layer
• business layer
• user interface

Se questi layer sono ben scritti e sufficientemente isolati gli uni dagli altri, sarà abbastanza semplice progettare interfacce utente di vari tipi (Windows Forms, WPF, Silverlight, ASP.NET, ecc) senza dover riscrivere tutta la logica business.

Nella mia esperienza personale sto trovando molto utile lo strumento "LINQ to SQL Classes", che evita di scrivere un sacco di codice per quanto riguarda l'interfacciamento con il database. Trasforma automaticamente le tabelle e i campi in altrettanti oggetti e membri. In pratica aggiungi lo strumento, apri una connessione al database e trascini dentro le varie tabelle, punto. Ti ritrovi il data layer praticamente finito. La sintassi di LINQ permette di gestire i dati alla stregua di collection, senza alcun bisogno di definire query SQL.

[the.ales]

è molto impegnativo come primo progetto, onestamente sono un pò demoralizzato...pero ehi, allo stesso tempo posso dire di avere fatto il terno al lotto se il programma piglia forma.
Comunque inizio già a darti noia con delle domande sceme (ti chiedo già scusa in anticipo...)

Cosa intendi per "scrivere un applicazione in layer?" Cioè posso scrivere un applicazione "a strati", e posso decidere io che parti far usare?

ho guardato "linq to sql"...spettacolo!
Ora me la studio ben bene per imparare a usarla, è potente.

[tas]

Per "layer" intendo dire che anziché scrivere tutto il codice nello stesso progetto lo separi in modo funzionale in più progetti.

La regola potrebbe essere questa:

• il codice dentro al "user interface layer" deve limitarsi a gestire le problematiche dell'interfaccia, delegando tutti i meccanismi di logica al "business layer"
• il codice dentro al "business layer" fornisce i metodi per l'accesso ai dati, gestendo i criteri di accesso e controllando tutto quello che entra ed esce.
• il codice dentro al "data layer" si occupa di interfacciarsi nel modo migliore con il database, eseguendo tutto ciò che gli viene detto di fare dal "business layer".

Un esempio banale: se dall'interfaccia devi salvare un record nel db, non scrivi tutto il codice dentro l'evento del pulsante, ma passi i dati da salvare a una funzione presente nel "business layer". Quest'ultimo non si limita a salvare ma controlla per esempio che la richiesta sia legittima o che i dati passati rispettino certe regole (per esempio un indirizzo email deve essere scritto correttamente). Le funzioni del "business layer" non utilizzano direttamente il database, ma si appoggiano ai metodi esposti dal "business layer" (che come detto potrebbe essere un oggetto "LINQ to SQL classes").

[the.ales]

ok, è ancora mezzo arabo, ma andando avanti comprenderò meglio!
Ovviamente (provo a chiedere solo "for fun"), tutte le funzioni di controllo devo crearle io vero? (tipo delle dll da aggiungere?)
Linq to sql classes mi crea una classe in automatico?
Esempio, ho creato per provare un piccolo db di nome studenti in sqlserver per provare la insert, la update e la delete.
Utilizzando linq to sql classes, mi crea un altro file ("DataClasses1.dblm"), e dentro ci ho schiaffato la tabella student...quindi ora nel program.cs ho una classe effettiva di tipo student?

[tas]

Si, dovresti avere a disposizione la classe Student.

Per accedere ai dati devi instanziare il data context, nel tuo caso dovrebbe essere qualcosa del genere:

DataClasses1DataContect dc = new DataClasses1DataContext();

Dal datacontext accedi alle varie tabelle che hai inserito nel dbml.

[the.ales]

Ok perfetto, grazie mille!
E scusa ancora per le domande stupide