In questa sessione vedremo come implementare il Repository pattern in modo da creare un Data Access Layer interrogabile mediante query LINQ, delegando l'effettiva esecuzione delle stesse ad O/RM quali Entity Framework e/o NHibernate.

1. Code Contracts and Generics:
implementing a LINQ-enabled
Repository
Andrea Saltarello
C.T.O.
http://blogs.ugidotnet.org/pape
http://twitter.com/andysal74
Managed Designs s.r.l.
http://creativecommons.org/licenses/by-nc-nd/2.5/

2. Sponsor
Sponsor Platinum
Sponsor Gold

3. Agenda
• Chi
• Quisquilie IT
• Perché
• Come
• Q&A

4. Repository pattern [P of EAA, 322]
Mediates between the domain and data mapping layers
using a collection-like interface for accessing domain
objects.

5. Code Contracts: OverView
I “Software Contract” sono specifiche formali del
comportamento di una unità di codice espresse mediante
l‟uso di 3 elementi:
• Espressioni invarianti, che sono vere sia prima sia dopo
l‟invocazione della funzione
• Precondizioni, che esprimono le condizioni nelle quali una
funzione può essere invocata
• Postcondizioni, che esprimono il funzionamento delle
funzioni
Nota: è possibile verificare questi elementi mediante l‟uso di
asserzioni, che implementeremo mediante unit testing

6. VS2010 vs. Code Contracts
Il FX 4.0 include il supporto ai Code
Contracts ma occorre «abilitarlo»
installando:
• il Code Contract toolkit per VS2010 (d/l da
sito Microsoft Research)
• [Opzionale] le estensioni Code Contract
per VS2010

7. Code Contracts

8. Repository pattern
A system with a complex domain model often benefits
from a layer, such as the one provided by Data Mapper
(165), that isolates domain objects from details of the
database access code. In such systems it can be worthwhile
to build another layer of abstraction over the mapping
layer where query construction code is concentrated. This
becomes more important when there are a large number
of domain classes or heavy querying. In these cases
particularly, adding this layer helps minimize duplicate
query logic.
…
You can also find a good write-up of this pattern in
Domain Driven Design.

9. Repository: as easy as 1-2-3
1. Il Repository occorre per persistere
un Domain Model
2. La «Bibbia» del Domain Model è
[DDD]
3. E vediamolo, „sto DDD 

10. DDD Architecture

11. DDD Key Concepts (redux)
• Il Domain Layer contiene la domain logic ed
è composto da
– Model: Entità (identità e stato) e Valori
(solo stato)
– Servizi
• Entità e Valori a runtime formano dei grafi
di oggetti. I grafi dotati di “dignità propria”
sono chiamati Aggregate e il sistema (es: i
Repository) si “impegna” a gestirli
correttamente ed atomicamente
• Le istanze di entità/aggregate sono costruite
da Factory (pattern Builder [GoF])

12. Da 0 ad Aggregate
• E' un insieme di elementi raggruppati in un‟unità
logica, quindi un grafo di oggetti
• Ha come radice l'entità principale dell'aggregato
• La radice è l‟unico elemento che può essere
referenziato fuori dai confini dell‟aggregato
• Non è possibile agire direttamente sugli elementi
senza passare dalla radice dell'aggregato
• L‟aggregate ha la responsabilità di implementare
la propria logica

13. Domain Model

14. Repository pattern (Reloaded)
Mediates between the domain and data mapping layers
using a collection-like interface for accessing domain
objects.
Ricapitolando:
• Interfaccia “collection like”
• Gestisce la persistenza degli Aggregate
• LINQ! (siamo dei buongustai )

15. IRepository<T>

16. Demo code: NSK
Progetto open source (licenza CPL)
disponibile su CodePlex:
http://nsk.codeplex.com

17. Bibliografia
[DDD] Domain Driven Design, Eric
Evans, Addison-Wesley
[P of EAA] Pattern of Enterprise
Application Architecture, Martin
Fowler, Addison-Wesley