Mi sa che hai complicato le carte in tavola...

Il problema di fondo è che io non lavoro in una software house! Bensì progetto e
sviluppo software per centrali idroelettriche e stazione AT/MT (vedi aeroporto
Malpensa 2000) utilizzando purtroppo software di terzi e non C# ( mi mancherebbe
tutta la parte di driver con i dispositivi in campo )

Quindi il mio approccio a .NET è praticamente "personale" e realizzo piccoli
tool per i clienti finali degli impianti o tool da utilizzare all'interno della
nostra azienda.

Fatta la premessa potrei dirti che avere una architettura SOA non è così
interessante, la maggior parte delle applicazioni pescano dati in locale o al
massimo in rete aziendale.

Guardandomi un pò in giro però mi stavo chiedendo se forse valeva la pena di
realizzarmi un set di classi che mi permettessero ad esempio di utilizzare
l'applicazione di protocollo informatico che abbiamo in azienda anche se con il
portatile sono in una delle tante aree coperte da UMTS senza per forza dovermi
connettere in VPN all'ufficio per dialogare direttamente con il DB.

Chiaro che qui MVVM non c'entra più e chiedo scusa se il discorso sta muovendosi
verso altri lidi.

Mauro

--- In ugialtnet@yahoogroups.com, "Mauro Servienti" <mauro.servienti@...> wrote:
>
> 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 <mailto:ugialtnet%40yahoogroups.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%40yahoogroups.com>
> [mailto:ugialtnet@yahoogroups.com <mailto:ugialtnet%40yahoogroups.com> ] On
> Behalf
> > Of Mauro
> > Sent: lunedì 29 giugno 2009 08:45
> > To: ugialtnet@yahoogroups.com <mailto:ugialtnet%40yahoogroups.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
> >
>