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 :-)
Un design pattern è soluzione generale e riusabile ad un problema ricorrente; ma tutti i design patterns "classici" possono essere utilizzati in Javascript? Esistono design patterns tipici di Javascript? In questo talk vedremo quali design pattern classici si possono implementare in Javascript, e come, così come nuovi pattern possono sfruttare al massimo le caratteristiche del linguaggio.
Loosely Coupled Complexity - Unleash the power of your domain modelFrancesca1980
Common software architectures are full of well-established assumptions. But some of them are flawed, no longer valid or relevant. Changing the rules of the game using DDD, CQRS and Event Sourcing can lead to systems which are more scalable, maintainable and performing. And which are fun to code as well.
"Don't call us, we'll call you" - AngularJS meets Event-Driven ArchitectureLuca Milan
Slides del talk del 21 Marzo al 1° AngularJS Day ad Ancona. Come realizzare una dashboard per consultare in tempo reale l'andamento dei piloti in una gara del MotoGP. Tutte le variazioni saranno notificate al client evitando il polling continuo al server. L'architettura dell'applicazione seguirà il paradigma della Command-Query-Responsibility-Segregation (CQRS) in 'salsa' REST.
Demo su: http://angularjsday.azurewebsites.net/
Un design pattern è soluzione generale e riusabile ad un problema ricorrente; ma tutti i design patterns "classici" possono essere utilizzati in Javascript? Esistono design patterns tipici di Javascript? In questo talk vedremo quali design pattern classici si possono implementare in Javascript, e come, così come nuovi pattern possono sfruttare al massimo le caratteristiche del linguaggio.
Loosely Coupled Complexity - Unleash the power of your domain modelFrancesca1980
Common software architectures are full of well-established assumptions. But some of them are flawed, no longer valid or relevant. Changing the rules of the game using DDD, CQRS and Event Sourcing can lead to systems which are more scalable, maintainable and performing. And which are fun to code as well.
"Don't call us, we'll call you" - AngularJS meets Event-Driven ArchitectureLuca Milan
Slides del talk del 21 Marzo al 1° AngularJS Day ad Ancona. Come realizzare una dashboard per consultare in tempo reale l'andamento dei piloti in una gara del MotoGP. Tutte le variazioni saranno notificate al client evitando il polling continuo al server. L'architettura dell'applicazione seguirà il paradigma della Command-Query-Responsibility-Segregation (CQRS) in 'salsa' REST.
Demo su: http://angularjsday.azurewebsites.net/
Strumenti di event driven analytics-sistemi evoluti di analisi degli eventiGabriele Marazzi
Le slide del Talk che ho tenuto il 4 luglio 2014 al Festival del WebMarketing a Roma. Organizzato da Gt Idea srl. Il talk aveva come obbiettivo quello di dare spunti utili per comprendere l'approccio culturale che vi è dietro l'analisi degli eventi, e non solo un mero elenco, o rassegna di tools e funzioni.
Assieme alla new economy ed all'avvento di internet ci sono stati diverse evoluzioni cui abbiamo assistito, il sorpasso del mobile sull'utilizzo del desktop, nel 2014 segna una fase. Ma anche la conoscenza che viene dall'approccio LEAN del Giappone degli anni 40 che oggi è largamente ripreso in diversi campi e non solo quello della produzione, è uno spunto interessante ed utile per comprendere una logica di analytics incentrata sulle persone, capace ad esempio di dare feedback che possono richiedere modifiche veloci.
Most software development processes are focused on tracking and delivery. Unfortunately, writing code is no longer the bottleneck. The real bottleneck is the team ability to learn about the domain complexity and do the right thing.
Too often we model processes around the myth of Database Transactions, ofter forgetting what a transaction really means in the real world. This talk shows an easy and cheap approach to use together with EventStorming in order to include User Experience into process modelling
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.
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.
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 ...)
Una PA agile, funzionale e serverless: si può fare! by Federico Feroldi and D...Codemotion
#Codemotion Rome 2018 - In questo talk raccontiamo il percorso del team che si è occupato della progettazione e dello sviluppo della piattaforma di messaggistica tra PA e cittadini a scala nazionale, prevista dal Piano Triennale per l'ICT della Pubblica Amministrazione. Quali sono state le difficoltà? Quali le vittorie? Cosa abbiamo imparato da questo percorso? La Pubblica Amministrazione è una macchina complessa, lenta, ma che, se gestita nel modo giusto può generare innovazione e tecnologia allo stato dell'arte.
Una PA agile, funzionale e serverless: si può fare! - Danilo Spinelli - Codem...Codemotion
In questo talk raccontiamo il percorso del team che si è occupato della progettazione e dello sviluppo della piattaforma di messaggistica tra PA e cittadini a scala nazionale, prevista dal Piano Triennale per l'ICT della Pubblica Amministrazione. Quali sono state le difficoltà? Quali le vittorie? Cosa abbiamo imparato da questo percorso? La Pubblica Amministrazione è una macchina complessa, lenta, ma che, se gestita nel modo giusto può generare innovazione e tecnologia allo stato dell'arte.
Una Pubblica Amministrazione Agile, Funzionale e Serverless: si può fare! - C...Federico Feroldi
In questo talk raccontiamo il percorso del team che si è occupato della progettazione e dello sviluppo della piattaforma di messaggistica tra PA e cittadini a scala nazionale, prevista dal Piano Triennale per l'ICT della Pubblica Amministrazione. Quali sono state le difficoltà? Quali le vittorie? Cosa abbiamo imparato da questo percorso? La Pubblica Amministrazione è una macchina complessa, lenta, ma che, se gestita nel modo giusto può generare innovazione e tecnologia allo stato dell'arte.
Code Contracts and Generics: implementing a LINQ-enabled RepositoryAndrea Saltarello
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.
Cos'è la UI Composition e che problemi può risolvere
Perchè MVVM e WPF sono importanti per la UI Composition
Il concetto di 'region' e 'UI Injection'
Analisi del toolkit PRISM di Microsoft e cosa comporta realizzarsene uno in proprio.
MongoDB User Group Padova - Overviews iniziale su MongoDBStefano Dindo
MongoDB è un database non relazionale, orientato ai documenti. Classificato come un database di tipo NoSQL, MongoDB si allontana dalla struttura tradizionale basata su tabelle dei database relazionali in favore di documenti in stile JSON con schema dinamico (MongoDB chiama il formato BSON), rendendo l'integrazione di dati di alcuni tipi di applicazioni più facile e veloce.
Lo scopo del MongoDB User Group Padova è quello di condividere esperienze sulla tecnologia MongoDB.
Questa presentazione, usata durante il primo evento dello User Group, è stata usata per introdurre i partecipanti sulle procedure di installazione ed i concetti di base su MongoDB.
Strumenti di event driven analytics-sistemi evoluti di analisi degli eventiGabriele Marazzi
Le slide del Talk che ho tenuto il 4 luglio 2014 al Festival del WebMarketing a Roma. Organizzato da Gt Idea srl. Il talk aveva come obbiettivo quello di dare spunti utili per comprendere l'approccio culturale che vi è dietro l'analisi degli eventi, e non solo un mero elenco, o rassegna di tools e funzioni.
Assieme alla new economy ed all'avvento di internet ci sono stati diverse evoluzioni cui abbiamo assistito, il sorpasso del mobile sull'utilizzo del desktop, nel 2014 segna una fase. Ma anche la conoscenza che viene dall'approccio LEAN del Giappone degli anni 40 che oggi è largamente ripreso in diversi campi e non solo quello della produzione, è uno spunto interessante ed utile per comprendere una logica di analytics incentrata sulle persone, capace ad esempio di dare feedback che possono richiedere modifiche veloci.
Most software development processes are focused on tracking and delivery. Unfortunately, writing code is no longer the bottleneck. The real bottleneck is the team ability to learn about the domain complexity and do the right thing.
Too often we model processes around the myth of Database Transactions, ofter forgetting what a transaction really means in the real world. This talk shows an easy and cheap approach to use together with EventStorming in order to include User Experience into process modelling
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.
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.
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 ...)
Una PA agile, funzionale e serverless: si può fare! by Federico Feroldi and D...Codemotion
#Codemotion Rome 2018 - In questo talk raccontiamo il percorso del team che si è occupato della progettazione e dello sviluppo della piattaforma di messaggistica tra PA e cittadini a scala nazionale, prevista dal Piano Triennale per l'ICT della Pubblica Amministrazione. Quali sono state le difficoltà? Quali le vittorie? Cosa abbiamo imparato da questo percorso? La Pubblica Amministrazione è una macchina complessa, lenta, ma che, se gestita nel modo giusto può generare innovazione e tecnologia allo stato dell'arte.
Una PA agile, funzionale e serverless: si può fare! - Danilo Spinelli - Codem...Codemotion
In questo talk raccontiamo il percorso del team che si è occupato della progettazione e dello sviluppo della piattaforma di messaggistica tra PA e cittadini a scala nazionale, prevista dal Piano Triennale per l'ICT della Pubblica Amministrazione. Quali sono state le difficoltà? Quali le vittorie? Cosa abbiamo imparato da questo percorso? La Pubblica Amministrazione è una macchina complessa, lenta, ma che, se gestita nel modo giusto può generare innovazione e tecnologia allo stato dell'arte.
Una Pubblica Amministrazione Agile, Funzionale e Serverless: si può fare! - C...Federico Feroldi
In questo talk raccontiamo il percorso del team che si è occupato della progettazione e dello sviluppo della piattaforma di messaggistica tra PA e cittadini a scala nazionale, prevista dal Piano Triennale per l'ICT della Pubblica Amministrazione. Quali sono state le difficoltà? Quali le vittorie? Cosa abbiamo imparato da questo percorso? La Pubblica Amministrazione è una macchina complessa, lenta, ma che, se gestita nel modo giusto può generare innovazione e tecnologia allo stato dell'arte.
Code Contracts and Generics: implementing a LINQ-enabled RepositoryAndrea Saltarello
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.
Cos'è la UI Composition e che problemi può risolvere
Perchè MVVM e WPF sono importanti per la UI Composition
Il concetto di 'region' e 'UI Injection'
Analisi del toolkit PRISM di Microsoft e cosa comporta realizzarsene uno in proprio.
MongoDB User Group Padova - Overviews iniziale su MongoDBStefano Dindo
MongoDB è un database non relazionale, orientato ai documenti. Classificato come un database di tipo NoSQL, MongoDB si allontana dalla struttura tradizionale basata su tabelle dei database relazionali in favore di documenti in stile JSON con schema dinamico (MongoDB chiama il formato BSON), rendendo l'integrazione di dati di alcuni tipi di applicazioni più facile e veloce.
Lo scopo del MongoDB User Group Padova è quello di condividere esperienze sulla tecnologia MongoDB.
Questa presentazione, usata durante il primo evento dello User Group, è stata usata per introdurre i partecipanti sulle procedure di installazione ed i concetti di base su MongoDB.
BigData & Graphs in Rome
OrientDB & Big Data:storie di vita vissuta
Da un caso di successo a un futuro che “spacca”
Un backstage di un caso di successo con un occhio critico ai problemi avuti, ma con la consapevolezza di un futuro brillante.
Il riassunto della nascita di una suite di business intelligence.
By Luca Bianconi
@LucaBianconi74
Grazie a Team Foundation Build è possibile adottare pratiche di integrazione continua nel proprio progetto. In questa presentazione viene introdotta la struttura di tfs build assieme alle tecniche base per effettuare una customizzazione della build.
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.
Similar to Layered Expression Trees feat. CQRS (20)
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.
When you use the Event Sourcing pattern in a .NET application, your data source just consists of persisted events. You don’t likely have a classic relational data store; all you store are events, and you store them sequentially as they occur in the domain. As you can guess, persisting events instead of a domain model has a significant impact on the way you organize the back end of the system. In this talk, we just develop a mini-ERP application that works out of distinct command and query stacks and persists just events. We also discuss how to rebuild state from events and see how to manage snapshot in order to speed up OLTP performances. Overall, this session presents a concrete example of an application architecture that for its inherent simplicity and maintainability is gaining momentum whether you have a complex business scenario to scale out or a just a CRUD system a bit more sophisticated than plain CRUD.
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.
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.
1. Layered Expression Trees
feat.
CQRS
Andrea Saltarello
C.T.O. @ managed/designs
http://blogs.ugidotnet.org/pape
http://twitter.com/andysal74
http://creativecommons.org/licenses/by-nc-nd/2.5/
2. Andrea Saltarello! Chi era costui?
• C.T.O. di Managed Designs, alla ricerca della
«sostenibilità dello sviluppo software»
1. Il cliente «deve» essere soddisfatto e pagare
2. Il fornitore «deve» avere un margine ragionevole
3. Il team «deve» essere soddisfatto del proprio lavoro
• (Co)Fondatore e presidente di UGIdotNET: ho
bisogno di condividere esperienze a causa del
bullet precedente
• (Co)Fondatore e collo di bottiglia di GUISA
• (Co)Autore di .NET: Architecting Applications
for the Enterprise di Microsoft Press
• Il #NAAE è il mio giornale di bordo, nel quale (nel
2008) ho cercato di «sintetizzare» i punti 1 e 2
6. Blue Book: Architettura (2/2)
è una layered architecture
i layer Presentation e Infrastructure
compaiono «per sport» nel diagramma
i layer Application e Domain costituiscono
quella che tipicamente chiamiamo «business
logic»
Domain: logica invariante rispetto ai casi d’uso
Application: logica specifica ai casi d’uso
7. Domain layer: Key Concepts
Il Domain Layer contiene la domain logic ed è
composto da
Model: Entità (identità e stato) e Valori (solo stato)
Servizi
Il Model è «both data and behaviour» (cit.)
La persistenza del Model è gestita da Repository
Le istanze delle entità di dominio sono costruite da
Factory
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
8. Application Layer: in teoria
Application Layer: defines the jobs the software
is supposed to do and directs the expressive
domain objects to work out problems. The tasks
this layer is responsible for are meaningful to the
business or necessary for interaction with the
application layers of other systems. This layer is
kept thin. It does not contain business rules or
knowledge, but only coordinates tasks and
delegates work to collaborations of domain
objects in the next layer down. It does not have
state reflecting the business situation, but it can
have state that reflects the progress of a task for
the user or the program.
9. Application Layer: in pratica
E’ un catalogo di servizi in grado di effettuare
il mesh della logica presente nel domain layer
esponendola alla applicazione (es:
presentation layer) in una forma ad… Alta
digeribilità.
11. Command Query Responsibility
Segregation
Command and Query Responsibility Segregation (CQRS)
originated with Bertrand Meyer’s Command and Query
Separation Principle. Wikipedia defines the principle as:
It states that every method should either be a command
that performs an action, or a query that returns data to
the caller, but not both.
Command and Query Responsibility Segregation uses the
same definition of Commands and Queries that Meyer
used and maintains the viewpoint that they should be
pure. The fundamental difference is that in CQRS objects
are split into two objects, one containing the Commands
one containing the Queries.
[Fonte: http://cqrsinfo.com/documents/cqrs-introduction/ ]
13. CQRS, a.k.a. «Stato di Diritto»
CQRS introduce in DDD la «separazione dei
poteri»
• 1 stack per «leggere»
• 1 stack per «eseguire»
In pratica, significa non dover «indovinare» un
modello valido per entrambe le esigenze
In questa sessione ci interessa la «Q»
14. Scenario 1: e-commerce
Home page: visualizzare prodotti raccomandati
Considerati tutti i prodotti catalogati, dall’elenco di
quelli in vendita presentare i 3 aventi maggior
giacenza in magazzino.
Ergo:
• Prodotti catalogati->Prodotti in vendita (domain)
• Prodotti in vendita->3 prodotti aventi maggior
giacenza (application)
15. Scenario 2: ERP
Visualizzare fatture insolute di una business unit
Considerate tutte le fatture, estrarre quelle attinenti
una business unit e tra esse visualizzare tutte quelle
scadute e non pagate a distanza di 30 gg dalla
scadenza
Ergo:
• Fatture emesse -> Fatture della BU
• Fatture BU -> Fatture scadute
• Fatture scadute -> Fatture insolute
16. Scenario 3: CMS
Visualizzare gli ultimi 5 articoli
Considerati tutti gli articoli, dall’elenco di quelli
pubblicati estrarre i 5 più recenti
Ergo:
• Articoli -> Articoli pubblicati
• Articoli pubblicati -> 5 articoli più recenti
17. Scenario 4: CMS (Reloaded)
Ricerca articolo
Considerati tutti gli articoli, dall’elenco di quelli
pubblicati estrarre quelli che soddisfano i criteri di
ricerca
Ergo:
• Articoli -> Articoli pubblicati
• Articoli pubblicati -> articoli che soddisfano la
query
18. Scenario 5: e-commerce (strikes back)
Ricerca prodotti
Considerati tutti i prodotti catalogati, dall’elenco di
quelli in vendita estrarre quelli che soddisfano i criteri
di ricerca.
Ergo:
• Prodotti catalogati->Prodotti in vendita
• Prodotti in vendita-> prodotti che soddisfano la
query
19. La «Q» in CQRS
Cosa hanno in comune questi casi?
• Ogni «filtro» è una regola che «lavora» sul
grafo
• Composizione di regole
• Ogni regola può essere usata in differenti
parti dell’applicazione
Come fare… Senza un «botto» di DTO?
P.S.: Si, «botto» è un ordine di grandezza del S.I. Kilo-
>Mega->Giga->Tera->Peta->Botto
20. Layered Expression Trees (LET idiom)
Facciamo un gioco: facciamo che layer e
servizi si scambino degli
IQueryable<YourFavouriteDomainEntity>
facendo «emergere» la query e specificando
la proiezione solo all’ultimo momento?
21. LET idiom feat. Ubiquitous Language
LET aumenta la pervasività dell’Ubiquitous
Language nel codice:
recommendedProducts = (from p in
CatalogServices.GetAvailableProductsOnSale()
orderby p.UnitsInStock descending
select new ProductDescriptor
{
Id = p.Id,
Name = p.Name,
UnitPrice = p.UnitPrice,
UnitsInStock = p.UnitsInStock,
}).Take(3);
Questa query è «quasi» scritta nel linguaggio del
Domain Expert
25. The Good
Ridotto effort di realizzazione/gestione:
• Nessun DTO (ad eccezione del ViewModel,
che avremmo comunque)
• Modello «database like» facile da ottenere
rapidamente
• Strutturazione «DDD like» della logica
• Se il DBMS è SQL Server, funziona «out of the
box»
Performance:
• Estrazione «all at once» di tutti e soli i dati
necessari
26.
27. The Bad
Unit testing «acrobatico»:
• In pratica, LINQ 2 Objects (o
similari)
• In ogni caso, è un LINQ provider
differente :-/ #meh
28.
29. The Ugly
• NHibernate è praticamente
inutilizzabile: il LINQ provider
«scoppia»
• Ogni LINQ provider è una storia a sè
31. LET idiom, v2
Se:
• dovessimo realizzare una applicazione e
non un framework
• per noi gli idiomi fossero «belli belli belli
in modo assurdo» (cit.)
…Allora potremmo rimpiazzare i servizi
con degli extension methods ad hoc
32. LET idiom, v2
public static class OutboundInvoiceExtensions
{
public static IQueryable<OutboundInvoice> RetrieveExpiredOutboundInvoices(this
IQueryable<OutboundInvoice> query)
{
var expiredInvoices = from i in query.RetrieveUnpaidOutboundInvoices()
where i.PaymentDueDate < DateTime.Now
select i;
return expiredInvoices;
}
public static IQueryable<OutboundInvoice> RetrieveUnpaidOutboundInvoices(this
IQueryable<OutboundInvoice> query)
{
var unpaidInvoices = from i in query
where i.Status == "E"
select i;
return unpaidInvoices;
}
public static IQueryable<OutboundInvoice> FilterByBusinessUnit(this
IQueryable<OutboundInvoice> query, int businessUnitId)
{
var invoices = from i in query
where i.JobOrder.BusinessUnit.OrganizationID == businessUnitId
select i;
return invoices;
}
}
33. LET2 feat. Fluent Ubiquitous Language
Sembra Specification ma non è, serve a darti l’allegria! (semi cit.)
expiredOutboundInvoices = from i in
ReadModelFacade.OutboundInvoices
.FilterByBusinessUnit(businessUnitId)
.RetrieveExpiredOutboundInvoices()
orderby i.PaymentDueDate
select new
SummaryViewModel.OutboundInvoice
{
Id = i.ID,
CustomerName = i.Customer.Name,
PaymentDueDate = i.PaymentDueDate.Value,
TotalAmount = i.TotalPrice,
JobOrderName = i.JobOrder.Name,
Code = i.Code
};
35. Bibliografia “pratica”
[DDD] Domain Driven Design, Eric Evans ,
Addison-Wesley
[NAAE] Microsoft .NET: Architecting
Applications for the Enterprise, Andrea
Saltarello & Dino Esposito, Microsoft Press
CQRS, Task Based UIs, Event Sourcing agh!,
Greg Young
[NSK] NSK, http://nsk.codeplex.com
Mio blog ENG,
http://blogs.ugidotnet.org/mrbrightside