Entità provienienti da più sorgenti

Ciao a tutti,

ho una applicazione 3-tiers che si basa su un modello ottenuto con
EntityFramework. Ora, per una seconda installazione,avrei bisogno di
"aggregare" le entità "al volo", prendendo da varie sorgenti di dati (db
del cliente, qualche WebService, ecc ecc...). Data la niubbagine, vi
chiedo: in questi casi, come ci ci muove?

Ciao,
Giulio
--

Ciao Giulio,

You wrote on 24/11/2009 :
> ho una applicazione 3-tiers che si basa su un modello ottenuto con
> EntityFramework. Ora, per una seconda installazione,avrei bisogno di
> "aggregare" le entit� "al volo", prendendo da varie sorgenti di dati (db
> del cliente, qualche WebService, ecc ecc...). Data la niubbagine, vi
> chiedo: in questi casi, come ci ci muove?

Cos� su due piedi, o meglio seduto sul treno :-), non vedo alternative
a fargli un'infrastruttura davanti che maschera la cosa e fa il disptch
delle varie chiamate ai vari storage... ma questo ti impedisce di usare
il dominio genrato da EF anche per le altre entit�

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Concordo con Mauro. Un'alternativa (ma a me non piace) è avere un ETL che ti aggrega tutto su di un unico database che poi viene acceduto da EF, ma in questo modo non hai i dati sempre aggiornati.

Se ci metti un IRepository<T> puoi giocare con un motore di inversione di controllo per fare si che un IRepository<Customer> ti vada su db e IRepository<Qualcosaltro> vada tipo su file, ma non è semplice da gestire, anche perchè un eventuale join tra le parti come le risolvi? Ovvero se devi joinare una cosA che sta su db ed una su file... la ved non banale.

alk.

Ciao alk,

innanzitutto grazie a te e a Mauro per i preziosi consigli (come al
solito).
Già che mi hai dato lo spunto, estendo un po' la discussione.

alkampfer wrote:
> Concordo con Mauro. Un'alternativa (ma a me non piace) è avere un ETL
> che ti aggrega tutto su di un unico database che poi viene acceduto da
> EF, ma in questo modo non hai i dati sempre aggiornati.

Soluzione presa in esame e scartata. :-)

> Se ci metti un IRepository puoi giocare con un motore di inversione
> di controllo per fare si che un IRepository ti vada su db e
> IRepository vada tipo su file, ma non è semplice da
> gestire, anche perchè un eventuale join tra le parti come le risolvi?
> Ovvero se devi joinare una cosA che sta su db ed una su file... la ved
> non banale.

Il problema è "a monte", nel senso che il mio è il caso in cui una entità:

class Foo
{
object pk { get; set; }
string Label { get; set; }
int Seed { get; set; }
}

va costruita (credo che mash-up) sia il termine corretto con alcuni dati
(es. Label) provenienti da un database e altri (es. Seed) provenienti da
un'altra sorgente. Si aggiunga che questo vale per il cliente B, mentre
per quello A siamo tranquilli tranquilli su un unico db, e per ora
l'idea è quella di utilizzare un modello generato mediante EF.

L'idea di fondo è quella di scrivere meno codice possibile (ovviamente)
e di poterlo riutilizzare il più possibile (ri-ovviamente). Ma la
situazione attuale non è delle più promettenti. :-) Spiego meglio:
attualmente c'è un application container che risolve diversi moduli che
lavorano su istanze di classi definite nel modello ottenuto con EF e con
i Controller dell'applicazione che "vedono" il modello stesso. Ad
esempio (in pseudo-meta-codice):

IFooModule fm =
ApplicationContainer.GetAppContainer().Resolve();
Foo foo = (new Entities()).Foo.Create();
fm.ApplyMethod(foo);
...blablabla...

Questo significa de facto dover buttare via tutto e ri-scrivere tutto da
capo. Una idea poteva essere quella di "astrarre" il modello verso le
interfacce (avendo quindi IFoo) ed esponendo nell'application container
un Repository che facesse da "façade" (o giù di lì) verso il mio
modello vero e proprio. Così facendo però mi perdo la comodità di poter
lavorare direttamente con delle query Linq (visto che se IFoo viene da
un mash-up di dati provenienti da più sorgenti non posso pensare di
eseguire query del genere). Va be' dai... la situazione l'avete capita,
no? ;-)

Ciao e grazie,
petrux

p.s. per chi volesse/potesse anche su IRC ci sono canali interessanti.
Su freenode c'è #c# e #aspnet mentre su azzurra c'è #c# (in italiano).
Purtroppo di architettura vera e propria non c'è nulla ma ognitanto su
#c# di azzurra se ne parla. Io ci sono e il mio nick è (ovviamente) petrux.

Ciao Giulio,

You wrote on 25/11/2009 :
> va costruita (credo che mash-up) sia il termine corretto con alcuni dati
> (es. Label) provenienti da un database e altri (es. Seed) provenienti da
> un'altra sorgente. Si aggiunga che questo vale per il cliente B, mentre
> per quello A siamo tranquilli tranquilli su un unico db, e per ora
> l'idea è quella di utilizzare un modello generato mediante EF.

pi� semplice vi faceva schifo?? :-)

> L'idea di fondo è quella di scrivere meno codice possibile (ovviamente)
> e di poterlo riutilizzare il più possibile (ri-ovviamente). Ma la
> situazione attuale non è delle più promettenti. :-) Spiego meglio:
> attualmente c'è un application container che risolve diversi moduli che
> lavorano su istanze di classi definite nel modello ottenuto con EF e con
> i Controller dell'applicazione che "vedono" il modello stesso. Ad
> esempio (in pseudo-meta-codice):
>
> IFooModule fm =
> ApplicationContainer.GetAppContainer().Resolve();
> Foo foo = (new Entities()).Foo.Create();
> fm.ApplyMethod(foo);
> ...blablabla...
>
> Questo significa de facto dover buttare via tutto e ri-scrivere tutto da
> capo. Una idea poteva essere quella di "astrarre" il modello verso le
> interfacce (avendo quindi IFoo) ed esponendo nell'application container
> un Repository che facesse da "façade" (o giù di lì) verso il mio
> modello vero e proprio. Così facendo però mi perdo la comodit� di poter
> lavorare direttamente con delle query Linq (visto che se IFoo viene da
> un mash-up di dati provenienti da più sorgenti non posso pensare di
> eseguire query del genere). Va be' dai... la situazione l'avete capita,
> no? ;-)

stica__i, direi che non hai altre soluzioni, resta molto ma molto
aperto il problema delle query incrociate:

voglio tutti gli IFoo la cui Label sia xyz e il cui Seed sia maggiore
di x

Devi astrarre la cosa e avere una rappresentazione in memoria del tuo
modello con tutti i dati e solo li puoi fare le query. Se una parte del
modello � persistita su db e una parte su Webservice, ad esempio, io
farei la query su db poi recupero tutti i dati dal webservice per
completare il mesh-up e infine scarto quello che non serve in base alla
query originale.

Per l'interrogazione dal client verso il tuo "MeshUpDataContext" linq
te lo fumi di certo, ma lo specification pattern ti risolve
probabilmente il 100% delle magagne.

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Concordo con Mauro.

Alk.

Ciao Mauro,

mauroservienti wrote:
> più semplice vi faceva schifo?? :-)

No, decisamente no.
Però abbiamo un problema di fondo: il cliente ha una parte dei dati che
servono al nostro modello su un proprio db, parte del sistema
informativo aziendale, a cui non possiamo accedere direttamente ma solo
tramite web service (o altro mezzo). Questo è un esempio generale di cui
- con mia somma sorpresa - non ho trovato riferimenti letterari.

> stica__i, direi che non hai altre soluzioni, resta molto ma molto
> aperto il problema delle query incrociate:
>
> voglio tutti gli IFoo la cui Label sia xyz e il cui Seed sia maggiore
> di x
>
> Devi astrarre la cosa e avere una rappresentazione in memoria del tuo
> modello con tutti i dati e solo li puoi fare le query. Se una parte del
> modello è persistita su db e una parte su Webservice, ad esempio, io
> farei la query su db poi recupero tutti i dati dal webservice per
> completare il mesh-up e infine scarto quello che non serve in base alla
> query originale.

Si, alla fine non avrei altra soluzione.

> Per l'interrogazione dal client verso il tuo "MeshUpDataContext" linq
> te lo fumi di certo, ma lo specification pattern ti risolve
> probabilmente il 100% delle magagne.

Uhm... sul discorso specification pattern ho le idee (credo) abbastanza
chiare. Mi rimangono ancora alcuni dubbi sull'implementazione (es: che
differenza c'è con un visitor che scorre tutti gli elementi di una lista
e lascia quelli "buoni"? e che impatto ha sulle performance?) ma non è
questo il luogo di affrontarli. Visto che è un forum di architettura,
parliamo di architettura. :-)

Ci sono dei problemi con cui (ultimamente) ho quotidianamente a che fare
ma di cui non trovo riscontro il letteratura. La cosa mi pare
assolutamente strana ma... probabilmente è un problema mio: ad esempio è
possibile che in tutti gli esempi/libri che trattino questi argomenti
non esistano relazioni molti-a-molti? ;-)

Va be'... cerco di formalizzare i problemi e poi apro un altro thread
"Massimi Sistemi". :-)
Intanto grazie delle dritte,
Giulio
--

Ciao Gulio,

You wrote on 26/11/2009 :
> Però abbiamo un problema di fondo: il cliente ha una parte dei dati che
> servono al nostro modello su un proprio db, parte del sistema
> informativo aziendale, a cui non possiamo accedere direttamente ma solo
> tramite web service (o altro mezzo). Questo è un esempio generale di cui
> - con mia somma sorpresa - non ho trovato riferimenti letterari.

perch� � complesso e concedimi il sarcasmo spesso chi scrive evita la
complessit� per partito preso perch� non ha la bench� minima esperienza
ma probabilmente ha semplicemente letto tanto... ;-)

>> stica__i, direi che non hai altre soluzioni, resta molto ma molto
>> aperto il problema delle query incrociate:
>>
>> voglio tutti gli IFoo la cui Label sia xyz e il cui Seed sia maggiore
>> di x
>>
>> Devi astrarre la cosa e avere una rappresentazione in memoria del tuo
>> modello con tutti i dati e solo li puoi fare le query. Se una parte del
>> modello è persistita su db e una parte su Webservice, ad esempio, io
>> farei la query su db poi recupero tutti i dati dal webservice per
>> completare il mesh-up e infine scarto quello che non serve in base alla
>> query originale.
>
> Si, alla fine non avrei altra soluzione.
>
>> Per l'interrogazione dal client verso il tuo "MeshUpDataContext" linq
>> te lo fumi di certo, ma lo specification pattern ti risolve
>> probabilmente il 100% delle magagne.
>
> Uhm... sul discorso specification pattern ho le idee (credo) abbastanza
> chiare. Mi rimangono ancora alcuni dubbi sull'implementazione (es: che
> differenza c'è con un visitor che scorre tutti gli elementi di una lista
> e lascia quelli "buoni"? e che impatto ha sulle performance?) ma non è
> questo il luogo di affrontarli. Visto che è un forum di architettura,
> parliamo di architettura. :-)

La "specification" � quella che viaggia dal client verso il server il
visitor � quello che la applica.

> possibile che in tutti gli esempi/libri che trattino questi argomenti
> non esistano relazioni molti-a-molti? ;-)

per certi versi molti-a-molti � un errori, e in molti casi condivido,
per altri ci sta, sta di fatto che il "mapping" tra i 2 mondi
(relazionale e oo) nel caso di molti-a-molti � tutto tranne che ben
definito

> Va be'... cerco di formalizzare i problemi e poi apro un altro thread
> "Massimi Sistemi". :-)
> Intanto grazie delle dritte,
> Giulio
> --

attendiamo con ansia :-)
..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Ciao Mauro,

mauroservienti wrote:
> perchè è complesso e concedimi il sarcasmo spesso chi scrive evita la
> complessità per partito preso perchè non ha la benchè minima
> esperienza
> ma probabilmente ha semplicemente letto tanto... ;-)

Probabile. Io dico solo che finora tutti gli esempi che ho trovato sono
lontani *anni luce* dalle mie esperienze *real world*.

> La "specification" � quella che viaggia dal client verso il server il
> visitor � quello che la applica.

Ok, grazie del chiarimento. Mi vado a rileggere il paper di Fowler. :-)

> per certi versi molti-a-molti è un errori, e in molti casi condivido,
> per altri ci sta, sta di fatto che il "mapping" tra i 2 mondi
> (relazionale e oo) nel caso di molti-a-molti è tutto tranne che ben
> definito

Ti faccio l'esempio più banale del mondo.
Ho un sistema in cui salvo dei link che mi interessano, ad ogni link
associo una serie di etichette, ossìa... delicious.com! :-) A livello
*puramente* logico, le mie entità sarebbero così:

class Link
{
string Url;
List Labels; //label associate al link corrente;
}

class Label
{
string Value;
List Links; //link a cui la label corrente è associata
}

E' un esempio molto SEMPLICE ma COMPLESSO (e non uno di quelli facili e
complicati, che si trovano in rete... chi vuol capire la finezza...). A
livello di db ho ovviamente tre tabelle, una per i link, una per le
label e una che è una associazione molti a molti tra le due precedenti.
Con EF ho generato un modello assolutamente simile a quello che ho
descritto qui sopra. Su una cosa del genere ci sarebbe da lavorarci UN
ANNO per scrivere esempi e postare domande qui... :-)

> attendiamo con ansia :-)

Ti sei scavato la fossa. :-)

Ciao e grazie,
Giuio
--

Ciao Giulio,

You wrote on 26/11/2009 :
> Probabile. Io dico solo che finora tutti gli esempi che ho trovato sono
> lontani *anni luce* dalle mie esperienze *real world*.

gli esempi sono semplici per definizione, altrimenti non sarebbero
esempi, scrivere un esempio complesso con tanto di documentazione a
corredo in stile pattern & pratices comporta un effort notevole.

>
> E' un esempio molto SEMPLICE ma COMPLESSO (e non uno di quelli facili e
> complicati, che si trovano in rete... chi vuol capire la finezza...). A
> livello di db ho ovviamente tre tabelle, una per i link, una per le
> label e una che è una associazione molti a molti tra le due precedenti.
> Con EF ho generato un modello assolutamente simile a quello che ho
> descritto qui sopra. Su una cosa del genere ci sarebbe da lavorarci UN
> ANNO per scrivere esempi e postare domande qui... :-)

sarebbe interessante farlo, tu con EF io con NH e vediamo che ne esce.

>> attendiamo con ansia :-)
>
> Ti sei scavato la fossa. :-)

:-P aiutatemi!! Gian Maria...!!!

> Ciao e grazie,
> Giuio
> --

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Ciao Mauro,

mauroservienti wrote:
> gli esempi sono semplici per definizione, altrimenti non sarebbero
> esempi, scrivere un esempio complesso con tanto di documentazione a
> corredo in stile pattern & pratices comporta un effort notevole.

A parte i soliti blog post... io sto parlando di *libri* (che sono
*pagati*).

> sarebbe interessante farlo, tu con EF io con NH e vediamo che ne esce.

Quando vuoi. :-)

> :-P aiutatemi!! Gian Maria...!!!

Puoi procurarti tutti gli aiuti del mondo... ;-)

Comunque, l'ultimo atto è questo.
Sto lavorando proprio all'esempio di cui ti parlavo. In poche parole EF
non permette di gestire relazioni molti a molti. La situazione è più o
meno questa: ho un db con tre tabelle
- Link(PK, Url) che contiene degli inditizzi web (e una chiave primaria,
PK);
- Label(value) che contiene una singola parola (che è anche chiave primaria)
- Tag(Link, Label) che contiene la PK di Link e il Value di Label.

Ho generato il modello con Entity Framework e le classi risultanti sono
(a spanne):

class Label
{
string Value;
EntityCollection Links;
}

class Link
{
int PK,
string Url;
EntityCollection Labels
}


che è esattamente quello che volevo. Ora, provando a far girare questp
snippet di codice:

LinkManagerEntities m = new LinkManagerEntities();
Link link = new Link();
link.Url = "http://www.google.com";
m.AddToLinkSet(link);

Label a = new Label();
a.Value = "a";
m.AddToLabelSet(a);

Label b = new Label();
b.Value = "b";
m.AddToLabelSet(b);

link.Labels.Add(a);
link.Labels.Add(b);
int n = m.SaveChanges();

TA-DAAAAAAN!
Unable to update the EntitySet 'tag' because it has a DefiningQuery and
no element exists in the
element to support the current operation.

Girovagando in rete sono riuscito a trovare molte informazioni a
riguardo, che vado ad elencare:
1. se una tabella non ha una chiave primaria, per EF non è una tabella
ma è una vista;
2. per fargliela vedere come tabella devi andare a modificare *a mano*
l'XML dell'entity data model (o trovato la modifica da qualche parte,
ora non la ritrovo, ma appena posso te la linko...);
3. se fai questa modifica non puoi più cancellare le altre entità
"correlate" alla tua relazione *-*
4. ...ma la cosa più bella è che se introduci una chiave primaria in una
tabella che è una relazione *-*, allora EF ti genera una entità a parte,
e addio relazione molti-a-molti nel modello.

In estrema sintesi: con EF non puoi avere relazioni molti-a-molti
funzionanti.
A me - chiedo scusa - pare una presa per il cu*o [1]. E capisco anche
chi denigra gratuitamente tutto ciò che è MS: è vero che metti su una
applicazione (banale) con due click, ma non hai il controllo di niente e
nel momento in cui ti serve qualcosa di strano (ammesso che una
relazione *-* sia qualcosa di strano) sei bruciato. E capisco anche il
perché della totale assenza di certi esempi nella documentazione
ufficiale (che più passa il tempo più peggiora) e non ufficiale: ti
immagini a tirare fuori un O/RM e dire: "però attenzione, perché non
potete fare relazioni molti-a-molti"? ;-) E poi arriva lo sca**o [2] di
dover lavorare in questo modo dopo aver sviluppato - per gioco - la tua
prima applicazione con l'AppEngine di Google... avete mai provato? Non
mi divertivo così da quando sono andato a Gardaland (avevo 9 anni). ;-)

Qualcuno ha qualche dritta (parlo di EF, non del mio "rant"...)? ;-)

[1] = cubo ;-)
[2] = scatto :-)

petrux wrote:
[cut]
> Qualcuno ha qualche dritta (parlo di EF, non del mio "rant"...)? ;-)

Problema risolto (più o meno).
Adesso però dvo andare in piscina.
Posterò domani (forse).

Ciao,
petrux

P.S.
http://blogs.msdn.com/alexj/archive/2009/09/01/tip-34-how-to-work-with-updatable-views.aspx
--