Having problems with message search?
Ciao,
Secondo me introdurre uno strato di servizi non è un’operazione
banale, con questo voglio dire che il passaggio da n-layer a n-tier è tutto
tranne che semplice e un’ottima architettura basata su n-layer non può
passare a n-tier così su due piedi.
L’inserimento di uno strato di servizi si fa se c’è
ragione di farlo, ad esempio scalabilità orizzontale, altrimenti è una sega
mentale (scusate il francesismo)
Facciamo un esempio “stupido” che fallirebbe
miseramente:
abbiamo la nostra bella architettura n-layer:
è db – DAL/Repository – UnitOfWork –
Presentation
La UoW in quanto tale gestisce il concetto di transazione sia di
business che fisica con il repository sottostante, adesso pensiamo di mettere
uno strato di servizi:
è db – DAL – entity2dto adapter – WCF .. wire
.. dto2entity adapter – DAL/Repository – UnitOfWork –
Presentation
Abbiamo inserito tutto quasi a caldo ma funziona? Neanche per le
balle... (questo è inglese tecnico), adesso il nostro buon sistemista che
conosce i file di configurazione di WCF dice: facciamo diventare il tutto “reliable”
e mettiamo nell’equazione una bella MSMQ Transazionale:
è db – DAL – entity2dto adapter – WCF .. MSMQ
.. dto2entity adapter – DAL/Repository – UnitOfWork –
Presentation
La nostra UoW all’atto del Commit:
-
Apre la Transazione
-
fa commit del changeset
-
e aspetta a vita che una transazione “disconnessa”
si chiuda... ma questo probabilmente non avverrà mai perchè la controparte
potrebbe non esserci... tanto abbiamo MSMQ quindi il sistemista ha messo il
server off-line per manutenzione;
e la nostra bella architettura fallisce miseramente ;-), in
realtà non è proprio così ma la semplificazione chiarisce bene uno dei tanti
problemi che SOA introduce.
La solfa (aka morale della favola) è che devo
disegnare/progettare per SOA che è radicalmente diverso dal
disegnare/progettare per non-SOA e lo faccio solo se ho il requisito, altrimenti
bagno di sangue + perdita di tempo/denaro assurda.
Ho risposto alla domanda o ho solo compilicato le carte in
tavola?
.m
______________________________________________________________
Mauro Servienti | mauro.servienti@... | Microsoft MVP -
Visual C# / MCP
From: ugialtnet@yahoogroups.com
[mailto:ugialtnet@yahoogroups.com] On Behalf Of Mauro
Sent: mercoledì 1 luglio 2009 15:41
To: ugialtnet@yahoogroups.com
Subject: [ugialtnet] Re: Openspace pattern MVVM
--- In ugialtnet@yahoogroups.com,
"Mauro Servienti" <mauro.servienti@...> wrote:
>
> Ciao Mauro,
> innanzitutto volevo scusarmi, ma mi sono reso conto solo quando ero in
> macchina sulla via del ritorno che tu sei il Mauro con cui ho scambiato
> qualche mail su quell'interessante progetto sul "designer", ti
meriti però
> una "cazziata" perchè avresti dovuto farti riconoscere ;-)
>
Hai ragione.. approvo la "cazziata".. colpa mia accidenti..
>
> Affrontiamo un punto alla volta:
>
>
>
> ViewModel:
>
Penso di aver capito che il problema più grande si ha quando devi far passare
gli oggetti attraverso strati intermedi come Validazione o altro
> DTO:
>
Dici che i DTO sono un must per WCF e qui cade anche la mia domanda su
applicazione multi-utente..
> Non ho capito quale sia la relazione tra applicazione "multi
utente" e dto
>
Mettiamo che devo sviluppare una applicazione multi-utente dove con questo
intendo che l'applicazione viene eseguita contemporaneamente da più utenti (per
essere pratici poniamo sia un gestionale).
In questa applicazione potremmo definire i classici layer
DAL
BLL
UI
In una applicazione di questo tipo prendereste in considerazione WCF come
strato aggiuntivo per blindare il DAL o DAL+BLL dietro ad un servizio WCF?
Oppure è sempre meglio avere un ORM e lasciare ad una sua corretta
implementazione la gestione della "multi-utenza"?
Qui entrano i DTO che in caso di WCF sarebbero "un must", in caso di
DAL "locale" potrei tranquillamente farne a meno.
> From: ugialtnet@yahoogroups.com
[mailto:ugialtnet@yahoogroups.com]
On Behalf
> Of Mauro
> Sent: lunedì 29 giugno 2009 08:45
> To: ugialtnet@yahoogroups.com
> Subject: [ugialtnet] Openspace pattern MVVM
>
>
>
>
>
>
>
>
> Sabato sono tornato a casa amareggiato dalla mia abissale ignoranza:
> rimanere fieri delle proprie conoscenze al fianco di
"personaggi" come Mauro
> Servienti, Massimiliano Mantione e gli altri BIG è stata davvero dura.
>
> A parte questa premessa, la prima conference di UgiALT.net a cui ho
> partecipato mi è servita tantissimo.
>
> Durante l'openspace su MVVM mi hanno colpito due affermazioni che riporto
di
> seguito e che vorrei approfondire:
>
> "Non creare ViewModel per ogni singolo oggetto"
> Questo vorrebbe dire a grandi linee di evitare di avere in un VM una cosa
> del tipo
>
> public ObservableCollection<CustomerViewModel> CustomersList {get;
set;}
>
> dovrei supporre quindi sia meglio evitare in generale di avere ViewModel
> figli di un ViewModel.
>
> "Non creare DTO se non necessari, altrimenti in grosse applicazioni
passi il
> tempo a modificare DTO"
>
> Mettiamo il caso che io voglia predisporre la mia applicazione per essere
> multi-utente: qual'è il limite superato il quale è meglio portare avanti e
> indietro entità complesse al posto di DTO?
>
> Avete post, articoli o altro da consigliarmi per approfondire queste
> tematiche?
>
> Grazie
>
> Mauro Destro
>
Offline 
Send Email