L'ingresso di Linq nel Framework è stato prepotente. I tangibili vantaggi di Linq to Sql e le promesse delle future versioni di Entity Framework hanno scatenato una vera e propria corsa a Linq. E pensare che siamo solo alle prove tecniche di trasmissione dei concetti di programmazione funzionale dentro il Framework ...
Mi è saltata in mente un'idea balzana. Ma voglio prima partire riaffermando alcuni concetti ormai consolidati da case studies e libri di fama:
- Le architetture multilayer sono più facili da difendere (sicurezza applicativa)
- L'astrazione con provider è un vantaggio in termini di evoluzione dell'applicazione e di manutenibilità
- I servizi (stateless) garantiscono un alto margine di scalabilità
Vediamo come sfruttare la programmazione funzionale in una architettura multilayer. Per esempio la UI:
- tipicamente esegue molte operazioni di selezione di entità caratterizzate da un certo numero di proprietà [projection]
- ha la necessità di filtrare i risultati [restriction]
- spesso deve paginare i risultati perché sono comunque troppi [partitioning]
- deve anche ordinare i risultati secondo un criterio [ordering]
- può avere bisogno di raggruppare [grouping] o di aggregare (sum, count, max, ...) [aggregation]
- ...
Tutto questo ricorda molto gli operatori di Linq 
Il service layer da parte sua espone già un contratto che permette una astrazione rispetto il data server o comunque le risorse sottostanti. Ma la difficoltà sta proprio nel contratto che il più delle volte è "ad hoc" per la nostra applicazione. Un domani che dovessimo usare un contratto differente, dovremmo necessariamente applicare una di queste soluzioni: (a) cambiare la UI per supportare il nuovo servizio, (b) creare un nuovo servizio che "trasformi" i dati con il nostro formato, (c) usare BizTalk per piallare le differenze.
L'idea balzana è semplice:
- usare i provider di Linq come "adapter" per lo strato dei servizi
- i provider useranno gli expression tree (che sono serializzabili) come "linguaggio" per mappare le richieste della UI sul servizio (Expression.Call esegue un determinato metodo)
- Le Expression.Call possono essere usate anche per le operazioni che non facciano mero retrieval di valori (per esempio insert/update/delete)
- usare sempre gli expression tree per le restriction (And, Not, Or, etc.). [Questo non esclude di poter avere oggetti di business differenti nel presentation e nel service layer in quanto convertire un expression tree non è complesso.]
- ...
Il vantaggio immediato è quello di ottenere un presentation veramente sterile, persino dai servizi; ...di avere una architettura a provider "gratis"; ...di avere i preziosi expression tree senza alcuno sforzo; ... di lavorare in modo strong-typed.
Sento già le ambulanze suonare ma io la vedo così...