Dopo tanto studiare, credo sia giunta l'ora di mettersi alla prova.
Voglio creare un piccolo programma di gestione delle attività di campagna per la mia azienda agricola.
Queste le risorse a disposizione:
- un numeroso team di sviluppo formato da una sola persona: io
- Visual Studio 2008 Pro
Alcune scelte architetturali
- Linguaggio di sviluppo: C#
- Applicazione: .NET 2.0 Windows Form
- Framework Gestione Dati: ADO.NET 2.0
- Database: SQL Server 2005
- Installazione: ClickOnce
L'idea è quella di sviluppare l'applicazione sul mio portatile (Sony Vaio, Vista Ultimate, 160 GB, 2 GB di ram) così posso lavorare a casa e in ufficio.
L'applicazione verà installata ed usata concorrentemente dai tre PC dell'ufficio (di cui due Win XP e uno Vista Ultimate), connessi in rete col server.
Prima di iniziare, però, voglio chiarirmi le idee su alcuni aspetti del ciclo di sviluppo:
- Pur essendo da solo (e bye bye al pair programming...) vorrei usare un source control system. Devo montare un VS 2008 TS sul server e un client sul mio portatile? Vado a chiederlo al mitico Lorenzo...
- Mi piacerebbe usare un ciclo di rilascio delle versioni molto breve, ma come faccio a gestire le varie versioni della base dati? Devo fare una capatina sul Forum di UGISS per fare un po' di domande a chi se ne intende.
il progetto, pur piccolino, è per me una scalata al monte Everest:
- Non ho mai sviluppato un'applicazione multi utente con ADO.NET 2.0 . Devo abbandonare il modello ACID in favore di quello disconnesso con la sincronizzazione e la gestione dei conflitti
- Sino ad oggi in VS 2005-2008 Pro ho solo scritto programmini di prova per fini di studio. Devo capire come impostare la struttura della soluzione, come suddividere i progetti all'interno della soluzione, come implementare il modello multi layer, il pattern MVC, ecc. ecc. .
Per finire: l'idea è quella di usare questo programma per cercare di fare esperienza su quanto ho appreso e tenere traccia su questo blog dei miei progressi e delle difficoltà incontrate.
Pur essendo da solo, voglio comunque tentare di applicare i principi di sviluppo che normalmente si usano in un team.
posted @ domenica 6 gennaio 2008 19:26