Scaricare la presentazione
La presentazione è in caricamento. Aspetta per favore
1
UGIALT.NET Conference II
UGIALT.NET Conference - 14 Giugno 2008 UGIALT.NET Conference II
2
Agenda della conference
10:00 – Benvenuto 10:15 – Introduzione a UGIALT.NET 10:30 – Lightning talks 11:00 – Pausa 11:15 – Prioritizzazione user stories 11:30 – Prima User Story introduttiva 12:00 – Users Stories 13:30 – Pranzo 14:30 – User Stories cont. 17:30 – Chiusura Lavori e futuro
3
Sponsor
4
Introduzione a UGIALT
5
Agenda Manifesto Storia Cosa significa ALT.NET Perchè ALT.NET
6
Manifesto Sei un dev che usa quello che funziona ma sei sempre alla ricerca di qualcosa di meglio Tieni d’occhio il resto del mondo per adottare il meglio da ogni community: Open Source, Agile, Java, Ruby, ecc… Non sei contento del tuo stato attuale. Le cose possono sempre essere migliorarate, codice più elegante e semplice, più manutenibile e di maggiore qualità Sai che I tools sono importanti, ma non ti portano molto lontano. Sono i principi e la conoscenza che contano. I tool migliori sono quelli che incorporano la conoscenza e incoraggiano I principi (ad. Es. Resharper)
7
Un po’ di storia Aprile 2007 – Il termine ALT.NET appare per la prima volta in un post di David Laribee Ottobre 2007 – Prima ALT.NET Conference ad Austin (TX) Novembre 2007 – Nasce UGIALT.NET Febbraio 2008 – 1° Conf UGIALT.NET Aprile 2008 – ALT.NET conf a Seattle
8
Cosa significa ALT ALT != Alternativo ALT == Avere Alternative
9
Perchè ALT.NET UserGroup tradizionali sono “about technology”
Più importante: Principi base dell’OOP Processi e metodologie di sviluppo Tool Alternativi
10
Ligthning Talks
11
Agenda Agilità (Emanuele DelBono) TDD (Roberto Valenti)
Mocking – Rhino (Claudio Maccari) IoC/DI (Simone Busoli) MVC/MVP (Simone Chiaretta) ORM (Matteo Baglini)
12
Agile Emanuele DelBono
13
Agilità Emanuele DelBono emanuele@codiceplastico.com
Agilità
14
Le metodologie tradizionali
15
Agility!
16
I tre capisaldi La femmina Il danaro La mortazza
17
I tre capisaldi (quelli veri)
Iterazioni Collaborazione Adattabilita’
18
Le persone non strumenti
le persone e le interazioni sono più importanti dei processi e degli strumenti
19
Software, non documentazione
è più importante avere software funzionante che documentazione
20
Il cliente collaborativo
collaborare con i clienti al di là del contratto
21
Adattarsi al cambiamento
essere pronti a rispondere ai cambiamenti più che aderire al planning
22
Perché? Fornire valore al cliente in breve tempo
Gestire il cambiamento Ridurre il rischio Migliorare la qualità Per divertirsi mentre si lavora!
23
Cos’è XP? XP è una metodologia basata su un insieme di pratiche:
Whole Team Planning Game Customer Tests Small Releases Simple Design Pair Programming Test Driven Development Design Improvement Continuous Integration Collective Code Ownership Coding Standard Metaphor Sustainable Pace
24
TDD Roberto Valenti
25
Cos’è Test Driven Development
Pratica di XP Sviluppo funzionalità guidato dai Test Attività di progettazione : Red : definire il comportamento atteso con asserzioni Green : rendere eseguibili con successo i test, le asserzioni sono verificate Refactor : effettuare refactoring mantenendo verificate asserzioni (eliminare duplicati, design pattern …)
26
TDD Mantra Processo TDD
27
Refactoring Migliorare il software tramite l’ applicazione di una serie di modifiche interne che non cambiano il comportamento esterno.
28
Scopo principale del TDD
Non è testare il codice. Aiutare sviluppatori e clienti durante il processo di sviluppo definendo requisiti non ambigui. TDD = Design (design emergente)
29
Velocità sviluppo tradizionale
Costo x Modifica nel Tempo
30
Tradizionale vs Agile Costo x Modifica nel Tempo
31
Benefici Codice semplice e funzionante Codice Testato
(Simple Design Principle) “Simplicity is more complicated than you think. But it’s well worth it” – Ron Jeffries Codice Testato (Test Behaviour Not Code) Facilmente manetunibile (Embrace Change) YAGNI (You Arent Gonna Need It) = No over design Microsoft al Teched a detto che loro non fanno qlc di simile perchè non saprebbero fare di meglio
32
Mocking Claudio Maccari
33
Rhino.Mocks Claudio Maccari Mail: cmaccari@absistemi.it
Blog (ITA): Blog (ENG): Rhino.Mocks
34
Cos’è Rhino.Mocks? Framework mock object per .net
Si parla di test… unit testing Ora disponibile versione 3.4 Microsoft al Teched a detto che loro non fanno qlc di simile perchè non saprebbero fare di meglio
35
Rende più semplice lo unit testing
Fake the hard stuff Risorse esterne Networks Databases Altri sistemi Risorse interne Qualsiasi cosa con setup complesso Legacy code
36
Si tratta di interazione
Objects talking to objects “State based testing” va bene “Interaction based testing” e più interessante
37
Struttura di un test con Rhino.Mock
Creazione di un mock Definizione delle comporamento atteso Esecuzione del codice sotto da testare Verifica delle aspettative Asserts addizionali
38
Basta chiacchiere Lets see some code!
39
Codice da testare
40
Test usando il mock
41
Per andare a fondo
42
Registra e ripeti La soluzione sta nel mezzo ?
43
Tipi di mock
44
Impostare le aspettative (1/2)
45
Impostare le aspettative (2/2)
46
Rhino.Mocks … Rocks! Download Wiki Quick Reference (ottimo documento)
Wiki Quick Reference (ottimo documento)
47
Q & A Dopo
48
IoC/DI Simone Busoli
49
Dependency Injection Inversion of Control
Simone Busoli 14/06/ Milano Dependency Injection Inversion of Control
50
Di cosa si tratta Comunemente DI - IoC
Principi comuni di disegno software Alta coesione Basso accoppiamento … Riduzione delle dipendenze tra componenti software Chi conosce chi? Risoluzione dipendenze tra componenti
51
Scenario Voglio poter registrare le iscrizioni ad un evento
Persistere i dettagli dell’iscritto Comunicare se l’iscrizione è andata a buon fine tramite mail SubscriptionService Service PersonRepository
52
Dependency Injection Elevato accoppiamento
SubscriptionService conosce direttamente i dettagli di Service e PersonRepository BAD
53
Dependency Injection Cambiamento di paradigma
Il servizio conosce solo l’interfaccia dei componenti che utilizza GOOD
54
Dependency Injection Iniettare dipendenze dall’esterno rende più onerosa l’istanziazione di componenti Necessario conoscere tutte le dipendenze
55
Vorrei un’istanza di SubscriptionService
Inversion of Control Hollywood Principle Don’t call us, we will call you! Vorrei un’istanza di SubscriptionService
56
Inversion of Control Container
Entità esterna all’applicazione Configurabile Conosce le dipendenze tra i componenti ed è in grado di soddisfarle a runtime IoC Container Vorrei un’istanza di SubscriptionService Istanza completa di tutte le dipendenze
57
Windsor Container Inversion of Control container open source
Stabile – production ready Si configura il container (xml, boo, C#) Si richiede l’istanza di un componente Il container si occupa di soddisfare le dipendenze e creare l’istanza
58
Windsor Container Esempio
Configurazione Xml
59
Windsor Container Esempio
Codice client Molto meglio, eh? Altri containers StructureMap Spring.Net Autofac …
60
Risorse Inversion of Control and Dependency Injection: Working with Windsor Container Castle Project StructureMap
61
MVC/MVP Simone Chiaretta
62
UI Patterns: MVC – MVP 14/06/2008 – Sim0ne Chiaretta
blog ITA: blog ENG: UI Patterns: MVC – MVP
63
It’s all about separation
Loose coupling Necessario rimuovere l’ambiente esterno Uomo WebServer
64
UI Pattern MVC – Model View Controller MVP – Model View Presenter
65
Model View Controller Model Controller View
66
Model View Presenter View Presenter Model IView
67
Dove si trovano in natura
MVC MonoRail ASP.NET MVC Framework Prism MVP Mostly custom built WebClientSoftwareFactory CompositeUIApplicationBlock
68
Come saperne di più su MVC
- Sito ufficiale, con download P2 - Codice sorgente - tutti gli articoli su ASP.NET MVC - lista “commentata” di risorse Blog di MS ScottGu: ScottHa: PhilHa: Leggendo il mio blog DotNetMarche – 27 Giugno – Testing automatizzato e Asp.NET MVC Framework
69
ORM Matteo Baglini
70
ORM - Object Relational Mapping
14/06/2008 – Matteo Baglini Mail: Blog: ORM - Object Relational Mapping
71
Quando e Perchè usare un ORM
72
Scenario Business Logic Layer modellato utilizzando il pattern Domain Model. Le tabelle del database secondo il modello relazionale RDBMS .
73
Problema Paradigm Mismatch ? ORM
74
Definizione di ORM L’ Object Relational Mapping è uno strumento che permette di mappare i dati fra il modello RDBMS ed il modello OOP.
75
Tecniche di Data Mapping
File XML Decorando Classi e Proprietà con Attributi
76
Vantaggi e Svantaggi
77
Vantaggi Permette di disegnare il modello seguendo la teoria OOP osservando solo la business logic. Approccio non più bottom-up ma top-down (dal dominio alla persistenza). Generazione automatica ed ottimizzata di statement sql creati ad hoc, i quali permettendo di gestire in maniera molto più granulare le operazioni CRUD.
78
Svantaggi Alta curva di apprendimento iniziale.
Leggeri compromessi nella progettazione del Domain Model, es. Implementare interfacce. Viene visto come “lo strumento” che permette allo sviluppatore di dimenticarsi del database.
79
ORM per .NET
80
I più famosi NHibernate Linq To Sql Entity Framework (Beta 3)
Open Source / Porting da Hibernate (Java) / Multi Database Vendor / Persistence Ignorance / Mapping Complessi Linq To Sql Supporto di MS/ Integrato con VS / Sintassi Linq / Molto Semplice Entity Framework (Beta 3) Supporto di MS/ Integrato con VS / Multi Database Vendor / Sintassi Linq / Mapping Complessi
81
Link Object Relational Mapping NHibernate/Hibernate
Wikipedia - C2.com - NHibernate/Hibernate Sito - Libro -
82
Link Linq To Sql Entity Framework
MSDN - Serie di di Post sul Blog di ScottGu - Entity Framework MSDN - CodePlex Samples-
Presentazioni simili
© 2024 SlidePlayer.it Inc.
All rights reserved.