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.
Repository Pattern: Un buon design al servizio della testabilitĂ .
Le slides si riferiscono al talk tenuto in Mikamai Milano durante i TDD Meetup di Milano, il 02/05/2017
A prima vista, MVC âis all about the presentation layerâ. In realtĂ , per trarre il massimo giovamento da questo toolkit è necessario progettare lâintera soluzione utilizzando criteri ad hoc.
In questa sessione vedremo come realizzare un Data Access Layer basato su una implementazione del Repository pattern ed in grado di essere interrogabile mediante query LINQ, eventualmente delegate ad O/RM quali Entity Framework e/o NHibernate. Vedremo inoltre come fare utilizzo dei Code Contracts del FX4 per specificare "una tantum" le regole comuni a tutti i repository di un Domain Model.
This set of design patterns are related to Enterprise Patterns. In it you can find, J2EE, Presentation, Business & Integration Patterns (such as: ApplicaCon Controller, Data Transfer Object (DTO), Business Object (BO) & Data Access Object (DAO) among others ...)
Never Mind the Bollocks: here's the Domain Driven DesignAndrea Saltarello
Â
La lettura del Blue Book può generare reazioni che vanno dal "Cargo cult" (a.k.a. "non avrai altro Modello allâinfuori di me") a "âsta roba non mi serve: io faccio gestionali, non applicazioni che lanciano i razzi sulla Luna".
Previa una attualizzazione dei concetti del Blue Book, che ha ormai compiuto 10 anni, in questa sessione affronteremo leggende metropolitane e falsi miti e implementeremo DDD mostrando poche slide e tanto codice.
Repository Pattern: Un buon design al servizio della testabilitĂ .
Le slides si riferiscono al talk tenuto in Mikamai Milano durante i TDD Meetup di Milano, il 02/05/2017
A prima vista, MVC âis all about the presentation layerâ. In realtĂ , per trarre il massimo giovamento da questo toolkit è necessario progettare lâintera soluzione utilizzando criteri ad hoc.
In questa sessione vedremo come realizzare un Data Access Layer basato su una implementazione del Repository pattern ed in grado di essere interrogabile mediante query LINQ, eventualmente delegate ad O/RM quali Entity Framework e/o NHibernate. Vedremo inoltre come fare utilizzo dei Code Contracts del FX4 per specificare "una tantum" le regole comuni a tutti i repository di un Domain Model.
This set of design patterns are related to Enterprise Patterns. In it you can find, J2EE, Presentation, Business & Integration Patterns (such as: ApplicaCon Controller, Data Transfer Object (DTO), Business Object (BO) & Data Access Object (DAO) among others ...)
Never Mind the Bollocks: here's the Domain Driven DesignAndrea Saltarello
Â
La lettura del Blue Book può generare reazioni che vanno dal "Cargo cult" (a.k.a. "non avrai altro Modello allâinfuori di me") a "âsta roba non mi serve: io faccio gestionali, non applicazioni che lanciano i razzi sulla Luna".
Previa una attualizzazione dei concetti del Blue Book, che ha ormai compiuto 10 anni, in questa sessione affronteremo leggende metropolitane e falsi miti e implementeremo DDD mostrando poche slide e tanto codice.
Evento XeDotNet sui Source Generators, una recente funzionalitĂ contenuta nellâSDK del compilatore .NET ("Roslynâ), che consentono agli sviluppatori C# di ispezionare il codice mentre viene compilato e generare al volo nuovi file sorgente C# aggiunti alla compilazione stessa. Vedremo come usarli e quanto possono essere utili nelle nostre applicazioni
Introduzione al Domain Driven Design (DDD)DotNetMarche
Â
In questa sessione si approfondirĂ il concetto di Domain Driven Design, un principio di progettazione che può essere visto come una âforma-mentisâ per aiutare a concepire e modellare applicazioni enterprise che fanno un forte uso del Domain Model. Questa metodologia, introdotta da Eric Evans, mette in risalto il dominio applicativo di un progetto, costituendo quindi il collante tra il modello analitico e il modello implementativo e trovando la sua naturale applicazione in ambienti di sviluppo agili come Extreme Programming. Come completamento della sessione verranno esaminate alcune tecniche di Layering e pattern architetturali che ben si sposano con questa tecnica.
CQRS, ovvero: 2 stack, uno per "leggere" e l'altro per "scrivere". Se per "scrivere" abbiamo l'imbarazzo della scelta (Domain Model, Command, Event Sourcing, ...) per leggere, invece, apparentemente c'è poco da dire. "Apparentemente", appunto. Parliamone :-)
L'Internet of Things è una realtà e primo o dopo avrà il suo impatto significativo nelle nostre aziende.
E a quel punto, i device saranno un asset di cui gestire il lifetime, alla pari dei nostri server, reti e cloud.
Azure IoT è la piattaforma su cui possiamo sviluppare la nostra soluzione IoT e cerchiamo di comprendere cosa significa amministrare un parco device.
Alcuni temi: protocolli di comunicazione e sicurezza del device e della comunicazione. Provisioning dei device. Gestione e monitoraggio dei dispositivi. Strumenti ed API a disposizione per l'IT Pro.
ASP.NET MVC è una piattaforma aperta costruita come un puzzle di componenti. Per personalizzare il comportamento dei componenti interni del sistema è quindi sufficiente rimuovere uno dei tasselli e sostituirlo con uno scritto da noi. Un'operazione resa semplice ed immediata dall'interfaccia Dependency Resolver.
Con l'avvento su scala globale di HTML5 le tecnologie web si sono evolute cercando di offrire all'utente una migliore esperienza applicativa sempre piĂš simile a quella desktop. Sul piano tecnico questo viene realizzato spostando la logica di presentazione sul browser client facendo leva su Javascript e CSS3. In questa sessione vedremo come KnockoutJS, un presentation framework Javascript basato sul pattern Model-View-ViewModel, permette di sviluppare Rich Internet Application (RIA) analizzando le sue caratteristiche implementative e mostrando esempi di casi reali anche in ambito mobile.
The Fine Art of Time Travelling: implementing Event SourcingAndrea Saltarello
Â
If there is a common practice in architecting software systems, it is to have them store the last known state of business entities in a relational database: this practice trades the easiness of implementation with the cost of losing the history of such entities. Event Sourcing provides a pivotal solution to this problem, giving systems the capability of restoring the state they had at any given point in time. Furthermore, injecting mock-up events and having them replayed by the business logic allows for an easy implementation of simulations and âwhat ifâ scenarios.
More Related Content
Similar to Code Contracts and Generics: implementing a LINQ-enabled Repository
Evento XeDotNet sui Source Generators, una recente funzionalitĂ contenuta nellâSDK del compilatore .NET ("Roslynâ), che consentono agli sviluppatori C# di ispezionare il codice mentre viene compilato e generare al volo nuovi file sorgente C# aggiunti alla compilazione stessa. Vedremo come usarli e quanto possono essere utili nelle nostre applicazioni
Introduzione al Domain Driven Design (DDD)DotNetMarche
Â
In questa sessione si approfondirĂ il concetto di Domain Driven Design, un principio di progettazione che può essere visto come una âforma-mentisâ per aiutare a concepire e modellare applicazioni enterprise che fanno un forte uso del Domain Model. Questa metodologia, introdotta da Eric Evans, mette in risalto il dominio applicativo di un progetto, costituendo quindi il collante tra il modello analitico e il modello implementativo e trovando la sua naturale applicazione in ambienti di sviluppo agili come Extreme Programming. Come completamento della sessione verranno esaminate alcune tecniche di Layering e pattern architetturali che ben si sposano con questa tecnica.
CQRS, ovvero: 2 stack, uno per "leggere" e l'altro per "scrivere". Se per "scrivere" abbiamo l'imbarazzo della scelta (Domain Model, Command, Event Sourcing, ...) per leggere, invece, apparentemente c'è poco da dire. "Apparentemente", appunto. Parliamone :-)
L'Internet of Things è una realtà e primo o dopo avrà il suo impatto significativo nelle nostre aziende.
E a quel punto, i device saranno un asset di cui gestire il lifetime, alla pari dei nostri server, reti e cloud.
Azure IoT è la piattaforma su cui possiamo sviluppare la nostra soluzione IoT e cerchiamo di comprendere cosa significa amministrare un parco device.
Alcuni temi: protocolli di comunicazione e sicurezza del device e della comunicazione. Provisioning dei device. Gestione e monitoraggio dei dispositivi. Strumenti ed API a disposizione per l'IT Pro.
ASP.NET MVC è una piattaforma aperta costruita come un puzzle di componenti. Per personalizzare il comportamento dei componenti interni del sistema è quindi sufficiente rimuovere uno dei tasselli e sostituirlo con uno scritto da noi. Un'operazione resa semplice ed immediata dall'interfaccia Dependency Resolver.
Con l'avvento su scala globale di HTML5 le tecnologie web si sono evolute cercando di offrire all'utente una migliore esperienza applicativa sempre piĂš simile a quella desktop. Sul piano tecnico questo viene realizzato spostando la logica di presentazione sul browser client facendo leva su Javascript e CSS3. In questa sessione vedremo come KnockoutJS, un presentation framework Javascript basato sul pattern Model-View-ViewModel, permette di sviluppare Rich Internet Application (RIA) analizzando le sue caratteristiche implementative e mostrando esempi di casi reali anche in ambito mobile.
The Fine Art of Time Travelling: implementing Event SourcingAndrea Saltarello
Â
If there is a common practice in architecting software systems, it is to have them store the last known state of business entities in a relational database: this practice trades the easiness of implementation with the cost of losing the history of such entities. Event Sourcing provides a pivotal solution to this problem, giving systems the capability of restoring the state they had at any given point in time. Furthermore, injecting mock-up events and having them replayed by the business logic allows for an easy implementation of simulations and âwhat ifâ scenarios.
This document discusses implementing event sourcing in .NET. It provides an overview of event sourcing and CQRS, noting that events capture past occurrences that affect the domain. A demo is shown of a sample event sourcing application using NServiceBus for messaging. The document recommends buying rather than building event store and messaging toolkit components, and lists options for each including SQL Server, MongoDB, RavenDB, MSMQ, NEventStore, and NServiceBus.
Applying DDD and CQRS can not only make the resulting design of our system simpler and more effective but, freeing us from the burdenof the âone model fits allâ approach, also allows architects to adopt different strategies when it comes to business logic modeling. Though lot has been written about DDD and CQRS, missing working code publicly available seems to be the elephant in the room: in this talk, weâll find out how to implement the âCommand side of the Forceâ by means of a proper Domain Model and getting to the point of switching from an entity based modeling to an event based one.
Learn how to design a web solution that exploits the ASP.NET stack: in this talk weâll find out how to set up an effective, idiomatic design that take advantage of both âout of the boxâ tools (e.g. MVC, Entity Framework) and bleeding edge, third party ones. Needing a SPA? Weâll understand how to take advantage of existing toolkits. Responsive design? Letâs talk Bootstrap looking at how it provides a useful and highly customizable taxonomy for UI elements. Having troubles implementing an efficient data access layer due to a lot of business rules? Weâll learn how to use LINQ as a mean to decompose those rules in simpler ones that can be composed in a flexible and efficient way. Are you concerned about performance and scalability issues? Weâll see how to implement CQRS in order to take advantage of ad hoc data models and introduce a service bus so to decouple front-end systems from back-end ones.
Layered Expression Trees: una terza via (idiomatica) verso il DDDAndrea Saltarello
Â
Abbiamo il nostro splendido Domain Model, e possiamo passare la vita a definire DTO per usarlo in modo âsostenibileâ. Oppure possiamo metterlo (un poâ) in disparte ed adottare CQRS, ammesso che non ci venga mai da dire: âche sprecoâ. Oppure possiamo optare per una terza via idiomatica: Layered Expression Trees. Parliamone.
The document discusses the history and concepts behind object-relational mapping (ORM) and ORMs. It begins by describing the mismatch between the object-oriented and relational models. It then covers early work on object-relational mapping to bridge this gap. This led to the development of ORM tools that allow defining object-relational mappings and querying object graphs that are persisted to databases. Key concepts discussed include object identity, object shadows, query objects, repositories, partitioning query results, the unit of work pattern, and identity maps. Code examples demonstrate these concepts using NHibernate and LINQ.
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
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 ď
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
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 ď)
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