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"