Bigino architetturale

Poichè il socio sta preparando le sue sessioni per la DevConnection di Londra, venerdi ci siamo "avventurati" in una delle nostre chat "tenniche". Man mano che proseguivamo ho pensato che, malgrado le imprecisioni e le "superficialità/approssimazioni" tipiche della "presa diretta", tutto sommato quanto stavamo scrivendo potesse costituire un interessante "bigino" architetturale e abbiamo deciso di pubblicarla. Piccola nota personale: *adoro* queste chat e la capacità di Dino di trasformare "piccoli appunti disordinati" in testi scorrevoli e IMVHO persino piacevoli da leggere. Una piccola parte di "Programmare ASP.NET 2.0" e il nostro articolo su MSDN Magazine sono nati così.

Dino ha inviato 22/02/2008 11.41:

eccomi

Dino ha inviato 22/02/2008 11.41:

pronto per la 1ma domandina del gg sui pattern?

Andrea, & the Waterloo Project scrive:

ci provo

Dino ha inviato 22/02/2008 11.50:

Ho passato la serata su NSK

Dino ha inviato 22/02/2008 11.50:

Vediamo se ho capito quello che hai/avete fatto

Andrea, & the Waterloo Project scrive:

 

Dino scrive:

C'è un "Service Layer"  visibile nelle classi XXXServices invocate dai client

Dino scrive:

e sotto c'è un DM che è un Manager (Service) Model ovvero un DM in cui behavior e dati sono in classi separate

Andrea, & the Waterloo Project scrive:

yy

Andrea, & the Waterloo Project scrive:

purtroppo si

Andrea, & the Waterloo Project scrive:

ma solo per mancanza di tempo

Dino scrive:

Cioè avresti voluto mettere tutto nelle classi entity?

Andrea, & the Waterloo Project scrive:

infatti nel "book time frame" ne effettuerò una importante ristrutturazione

Andrea, & the Waterloo Project scrive:

yy

Andrea, & the Waterloo Project scrive:

il concetto è questo

Andrea, & the Waterloo Project scrive:

la "business logic" si compone di 2 categorie di logica: Domain Logic e Application Logic

Andrea, & the Waterloo Project scrive:

l'idea è "semplice"

Andrea, & the Waterloo Project scrive:

quando introduci un DM, il DM *è* il db agli occhi della applicazione

Andrea, & the Waterloo Project scrive:

concordi con questo punto?

Dino scrive:

assolutamente

Dino scrive:

lo dice MF

Andrea, & the Waterloo Project scrive:

(db==database, quindi "archivio". Archivio!=DBMS)

Andrea, & the Waterloo Project scrive:

bene

Andrea, & the Waterloo Project scrive:

i database sono tipicamente condivisi tra aplicazioni differenti

Andrea, & the Waterloo Project scrive:

orbene, *tutta* la logica che applicazioni differenti condividerebbero se usassero lo stesso object (pardon, "domain") model è domain logic

Andrea, & the Waterloo Project scrive:

tutto il resto è  "application logic"

Andrea, & the Waterloo Project scrive:

in pratica, si dice che l'application logic "implementa" i casi d'uso

Andrea, & the Waterloo Project scrive:

quindi:

Domain Logic->Domain Model

Application Logic -> Servizi

Andrea, & the Waterloo Project scrive:

(questo perchè, ovviamente, applicazioni differenti presentano casi d'uso differenti)

Dino scrive:

chiaro

Andrea, & the Waterloo Project scrive:

ma veniamo alla parte che prob ti interessa di +

Andrea, & the Waterloo Project scrive:

(attento: sto "sondando" la tua mente...)

Dino scrive:

tutto questo è chiarissimo

Andrea, & the Waterloo Project scrive:

tu stai pensando ad "LINQ e ASP.NET MVC"

Dino scrive:

no. Non ancora ;

Andrea, & the Waterloo Project scrive:

io lo so, i miei superpoteri non possono fallire

Dino scrive:

Sto lavorando su una presentazione DevConn su DL

Andrea, & the Waterloo Project scrive:

ah, allora sarò bocciato al corso di supereroe

Andrea, & the Waterloo Project scrive:

(e pensare che avevo anche comprato "Superhero in 21 days")

Dino scrive:

di ASP.NET MVC mi occuperò seriamente dopo

Andrea, & the Waterloo Project scrive:

beh, il concetto è che i servizi "scriptano" il DM e usano il DAL per manipolarlo

Andrea, & the Waterloo Project scrive:

quindi in ottica .NET 3.5 la GUI consuma i servizi, e i servizi smanettano sul DM (magari usando LINQ)

Andrea, & the Waterloo Project scrive:

a qsto punto, i servizi possono fare 2 cose

Andrea, & the Waterloo Project scrive:

1) spediscono indieto alla GUI le istanze del DM che servono al presentation layer

Andrea, & the Waterloo Project scrive:

2) i servizi travasano gli oggetti del DM dentro dei DTO e restituiscono i DTO alla GUI, che è quindi agnostica al DM. "This is SOA"

Dino scrive:

chiarissimo anche questo--finalmente

Andrea, & the Waterloo Project scrive:

meno male

Andrea, & the Waterloo Project scrive:

pens che di solito si annoiano tutti quando dico (da anni) qste cose

Dino scrive:

Una domanda complementare è sul domain model suddiviso in 2 classi: entity + behavior

Dino scrive:

mi pare di capire che NON ti piace e NON lo consiglieresti

Dino scrive:

vediamo se sto capendo proprio al volo il perche

Andrea, & the Waterloo Project scrive:

già: DM è "both data and behaviour"

Andrea, & the Waterloo Project scrive:

dimmi

Dino scrive:

con i servizi che scriptano il DM, avere due classi è "burtto"

Dino scrive:

perche' i servizi devono "sapere" che ci sono due classi Customer & CustomerManager o come la chiamiamo

Andrea, & the Waterloo Project scrive:

posso risponderti scrivendo codice?

Dino scrive:

se preferisic...

Andrea, & the Waterloo Project scrive:

immgina di avere un servizio che fa dei calcoli sui prodotti "Top"

Andrea, & the Waterloo Project scrive:

che che un prodotto "Top" sia tale in funzione si una business rule

Andrea, & the Waterloo Project scrive:

ergo, la properietà Top della classe Product non esiste sul db, ma è calcolata

Andrea, & the Waterloo Project scrive:

bene, il servizio potrà ottenere i dati di cui necessita mediante la quesry:

Andrea, & the Waterloo Project scrive:

var topProduct = from p in {tuocontext} where p.IsTop==true select p;

Andrea, & the Waterloo Project scrive:

ed ecco che hai "consumato" domain logic

Andrea, & the Waterloo Project scrive:

(con NH avrei scritto in HQL: "FROM Product p WHERE p.IsTop==true")

Dino scrive:

mentre se hai behavior altrove non puoi scrivere quel codice e devi ricorrere ad un altro oggetto che ti da i prodotti TOP facendo la qiery classica e poi filtrando

Andrea, & the Waterloo Project scrive:

yep, esatto

Dino scrive:

chiaro

Andrea, & the Waterloo Project scrive:

davvero? guarda che poi mi monto la testa

Dino scrive:

BENE BENE--questa era per il pome ma visto che hai citato NH ...

Dino scrive:

te la becchi subito e pome facciamo festa

Andrea, & the Waterloo Project scrive:

ROTFL

Dino scrive:

Su NSK ho visto che ci sono vari strati di DAL--SqlServer, MsAccess e ... Hibernate

Dino scrive:

giusto?

Andrea, & the Waterloo Project scrive:

yy, esatto

Dino scrive:

Non mi torna il parallelo Hibernate/Sql Server

Dino scrive:

Dovrebbe essere AdoNet/Hibernate

Andrea, & the Waterloo Project scrive:

bene, è un ottimo punto di partenza

Dino scrive:

Hibernate poi è indipendente dal DMBS, giusto?

Andrea, & the Waterloo Project scrive:

nope, perchè NSK affronta un altro requisito

Andrea, & the Waterloo Project scrive:

ossia il fatto che le strutture dei db possano essere differenti

Dino scrive:

il db fisso?

Andrea, & the Waterloo Project scrive:

ergo, il DAL per SQL server potrebbe usare tabelle/view/stored proc che su Access non ci sono

Andrea, & the Waterloo Project scrive:

se avessi solo Hibernate, non ci sarebbe problema

Andrea, & the Waterloo Project scrive:

perchè "annegherei" tutto ciò nei file di mapping

Andrea, & the Waterloo Project scrive:

ma nel caso di ADO.NET faccio provider specifici per ogni db, anche se tutti i provider basati su ADO.NET estendono un providerbase

Andrea, & the Waterloo Project scrive:

questo è un punto controverso di NSK

Dino scrive:

Cercando di astrarre e quindi andando oltre NSK e piu' verso un sistema reale

Andrea, & the Waterloo Project scrive:

okappa

Andrea, & the Waterloo Project scrive:

allora ti pongo una domanda

Dino scrive:

vai

Andrea, & the Waterloo Project scrive:

nello "scenario reale" useresti un ORM?

Dino scrive:

direi proprio di si

Andrea, & the Waterloo Project scrive:

okappa

Andrea, & the Waterloo Project scrive:

allora è semplice

Andrea, & the Waterloo Project scrive:

non esiste un DAL astratto e i servizi usando direttamente l'API dell'ORM, LINQ o NH che sia

Andrea, & the Waterloo Project scrive:

e delegherei la possibilità di cambiare DB all'ORM e non a dei provider specifici

Dino scrive:

ah ecco

Andrea, & the Waterloo Project scrive:

il che, ovviamente, "taglia" LINQ 2 SQL

Andrea, & the Waterloo Project scrive:

quindi: i servizi contengono direttamente query LINQ (Entity Framework come ORM) o HQL (NHibernate) o OQL/LINQ (Genome)

Dino scrive:

Ovviamente posso creare classi intermedie estrando interfacce o vado proprio giù brutale?

Andrea, & the Waterloo Project scrive:

intermedie tra i servizi e l'ORM?

Dino scrive:

si

Dino scrive:

che incapsulano le query LINQ, HQL, etc

Andrea, & the Waterloo Project scrive:

quale vantaggio vorresti trarne? così capisco

Dino scrive:

Una sorta di DAL astratto--in NSK ci sono classi provider

Andrea, & the Waterloo Project scrive:

si, ma ci sono perchè volevo avere sia NH sia ADO.NET

Dino scrive:

o e' tempo perso?

Dino scrive:

capito

Andrea, & the Waterloo Project scrive:

ma nel mondo reale andrei con NH (o EF) e basta

Andrea, & the Waterloo Project scrive:

ergo, non implementerei classi intermedie

Andrea, & the Waterloo Project scrive:

tornado a qnto detto ieri

Andrea, & the Waterloo Project scrive:

se ci fossero "n" servizi che eseguono una query *identica* creerei un repository che espone qlle query

Andrea, & the Waterloo Project scrive:

ma sarebbe solo per un refactoring teso ad elimnare lo smell "duplicated code"

Dino scrive:

Ottimo

Dino scrive:

Ultima cosa: se non uso un ORM devo procedere come in NSK con le classi DAL mie

Andrea, & the Waterloo Project scrive:

si, direi di si

Dino scrive:

E in tutto questo: LINQ-to-SQL?

Dino scrive:

In NSK, lo uso come ulteriore strato tipo SqlServerLinq?

Andrea, & the Waterloo Project scrive:

in tutto questo, LINQ 2 SQL è un ORM con 2 problemi:

1) scarse capacità di mapping

2) supporto SQL-Server only

Dino scrive:

certo--limitatamente alle sue capacita

Andrea, & the Waterloo Project scrive:

hai detto niente

Dino scrive:

 

Dino scrive:

Lo faccio per capire

Andrea, & the Waterloo Project scrive:

in NSK uso dei "component", ma LINQ 2 SQL non supporta qsta strategia di mapping

Dino scrive:

Diciamo--L2SQL al posto di ADO.NET

Andrea, & the Waterloo Project scrive:

ah, ok

Dino scrive:

sul DM esistente

Andrea, & the Waterloo Project scrive:

e allora usi L2SQL per fare delle query che recuperano una parte del DM, e poi scrivi codice per riempire le proprietà che L2SQL non sa gestire

Andrea, & the Waterloo Project scrive:

ma è un po' una porcheria

Andrea, & the Waterloo Project scrive:

purtroppo il DM di NSK è persistence ignorant

Andrea, & the Waterloo Project scrive:

ergo, non è modellato pensando alle feature di un DAL specifico

Andrea, & the Waterloo Project scrive:

e quindi L2SQL non riesce a gestirlo

Dino scrive:

Ma il DM deve essere "persistence ignorant" giusto=

Andrea, & the Waterloo Project scrive:

(es: l'indirizzo è donormalizzato sul db Northwind, mentre nel DM esistono classi apposite)

Andrea, & the Waterloo Project scrive:

yy, dovrebbe

Andrea, & the Waterloo Project scrive:

l'unica alternativa è che usi L2SQL per tirarti su degli oggetti interni al DAL, e poi scrivi codice che li travasa del DM

Dino scrive:

La mia idea è poprio questa

 

Andrea, & the Waterloo Project scrive:

in pratica, utilizzando L2SQL come "ADO.NET object based" invece di "tuple based"

Dino scrive:

infatti--non vale lo stavo scrivendo io

Andrea, & the Waterloo Project scrive:

 

Dino scrive:

alla fine, è quello per cui è fatto

Andrea, & the Waterloo Project scrive:

senti... ti va se pubblico qsta chat nel blog?

Dino scrive:

e va bene nella maggior parte dei progetti

Dino scrive:

Capperi -- certo

Andrea, & the Waterloo Project scrive:

okappa

Andrea, & the Waterloo Project scrive:

allora dopo lo faccio

Dino scrive:

io comunque me la salvo

Dino scrive:

 

Andrea, & the Waterloo Project scrive:

LOL

Dino scrive:

Sono 3 gg che non gioco a tennis per capire queste cose--stasera ricomincio

Andrea, & the Waterloo Project scrive:

bene

Andrea, & the Waterloo Project scrive:

BTW, Federer che perde è stato uno shock

Andrea, & the Waterloo Project scrive:

prova a capirmi: nel giro di 12 mesi solari l'Inter vince uno scudetto e vedo Federer perdere un match importante... temo stia per scatenarsi l'Apocalisse

Dino scrive:

Per gg ho avuto "Caduta del governo Federer" come nick su Messenger

Andrea, & the Waterloo Project scrive:

si, lo avevo visto

Dino scrive:

Ieri ho dovuto citare la sconfitta di Federer con mio figlio che mi ha detto (pagella tutti OTTIMO): ma perchè nessuno mi fa i complimenti per questo?

Dino scrive:

ai bravi capita questo, perdi in semifinale e sei una pippa

Andrea, & the Waterloo Project scrive:

già

Dino scrive:

Ergo per oggi a te niente complimenti

Andrea, & the Waterloo Project scrive:

LOL. Lo avevo "intuito"

posted @ Sunday, February 24, 2008 12:59 PM

Print

Comments on this entry:

# Re: Bigino architetturale

Left by Michele Bersani at 2/24/2008 2:14 PM
Gravatar
Bellissimo!
Da questa chat secondo me ne verrebbe fuori un bell'articolo, questi sono i punti di cui avete discusso...
1) Differenza fra behaviour e dati in classi separate o insieme (casi d'uso)
2) Differenza fra Domain Logic e Application/Service Logic e perche' vanno separati
3) Comunicazione fra Servizi e DM
4) Comunicazione con il client (Oggetti DM vs DTO)
5) DAL astratto vs ORM API (EF o NHibernate)
6) Possibilita' di cambiare il DB
7) L2SQL e limitazioni
8) Federer e l'Inter - ah no, questo no.. ;)

# re: Bigino architetturale

Left by Alessio at 2/24/2008 2:18 PM
Gravatar
Grazie per aver pubblicato questo post, è interessantissimo e mi torna utile per chiarire un paio di punti visto, che sto tenendo un corso dove ho introdotto NSK come progetto d'esempio per parlare di architetture. Anche se mi sa che in settimana ti invierò una mail per chiederti qualche altra info al riguardo e un parere su un approccio che ogni tanto seguo ;)

# Re: Bigino architetturale

Left by Roberto Messora at 2/24/2008 2:21 PM
Gravatar
bene, allora tronfio di me stesso, sono contento di avere la benedizione del Presidente ad un decisione presa da qualche mese: LINQ2SQL non è compliant con la mia architettura di riferimento.
Nell'attesa di una implementazione seria di LINQ2NHibernate.
Amen.
Saluti

# re: Bigino architetturale

Left by Mario Duzioni at 2/25/2008 9:09 AM
Gravatar
Andrea, mi spaventi evidenziando sempre di più il "both data and behaviour", ma seguendo l'esempio mi sono tranquillizzato un po'... :-)

Grazie 1k per questo "corso accelerato" (grazie al TORCHIO!!) e... complimenti!! Così dimostriamo al figlio di Dino che, RARAMENTE, arrivano anche quelli! :-D
Ciao!
Comments have been closed on this topic.
«September»
SunMonTueWedThuFriSat
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345