Include serve per caricare dati di tabelle collegate. Esempio se devi elencare le categorie dei prodotti non serve l'include, perchè non ti serve caricare i dettagli di ogni prodotto, ma solo di quelli che ti interessano veramente.
Se invece devi mostrare un riepilogo delle fatture, dove sono presenti dati del cliente, prodotto, etc... allora metti in Include tutte le classi (tabelle) di cui hai bisogno.

Spero di aver reso bene l'idea

Non hai veramente capito qualcosa fino a quando non sei in grado di spiegarlo a tua nonna.
-Albert Einstein-
170 messaggi dal 17 febbraio 2009
fileman ha scritto:
Include serve per caricare dati di tabelle collegate. Esempio se devi elencare le categorie dei prodotti non serve l'include, perchè non ti serve caricare i dettagli di ogni prodotto, ma solo di quelli che ti interessano veramente.
Se invece devi mostrare un riepilogo delle fatture, dove sono presenti dati del cliente, prodotto, etc... allora metti in Include tutte le classi (tabelle) di cui hai bisogno.

Spero di aver reso bene l'idea



Dunque, hai reso bene l'idea, però non ho capito se è ciò di cui avevo bisogno.

Qui c'è il mio Object Model
http://85.39.202.194/MioModello.gif

Come puoi notare le category sono in relazione 1:N con i prodotti e sempre 1:N con le Proprietà di ogni categoria. Ti spiego perchè ho adottato questa soluzione (parziale).
Il software deve poter gestire in modo dinamico le categorie e le proprietà di ogni categoria. Es: Categoria: Tessuto, aggiungo alla tabella PropertyCategory: Misura, Colore, TipoTessuto, Ecc..
Dovrò inserire un'altra entità (tabella) che conterrà i valori di ogni proprietà per ogni prodotto appartenente ad una categoria; dunque una relazione N:N. Spero di aver reso l'idea di ciò che vorrei realizzare.

Risolto il problema della relazione tra prodotto e categoria.... leggendo il manuale LINQ era la soluzione a tutto!! :)

 
Public Function GetAllProductsWithCategories() As IList

        Return product_repository.GetAll.Select(Function(p As Product) New With {.Prodotto = p.Name, .Codice = p.Code, .Categoria = p.Category.Name}).ToList()

    End Function


ps: Hai consigli circa il modello da implementare ?!

pss: Fileman di ringrazio molto per i consigli e la pazienza, ma se ne sto abusando fammi un fischio
Modificato da vailfox il 07 dicembre 2010 23.59 -
170 messaggi dal 17 febbraio 2009
Secondo voi quale potrebbe essere una buona tecnica per implementare il modello che ho espresso nel post precendente??

Sono 2 giorni che ci rifletto ma non riesco a trovare una possibile soluzione ...
Modificato da vailfox il 07 dicembre 2010 23.58 -
io per una cosa simile, non proprio uguale, ho fatto così:

Categories:
IDCategory
Name

TypeCategoryProperties:
IDTypeCatProp
TypeCategoryProperty

CategoryProperties:
ID
IDCategory
IDTypeCatProp
Value

Fileman di ringrazio molto per i consigli e la pazienza, ma se ne sto abusando fammi un fischio

Nessun problema.

Non hai veramente capito qualcosa fino a quando non sei in grado di spiegarlo a tua nonna.
-Albert Einstein-
170 messaggi dal 17 febbraio 2009
Se ho ben capito, la soluzione esposta da te consente di memorizzare un solo valore per ogni tipo di categoria.

A me servirebbe una soluzione simile ma dovrei caricare n valori di proprietà di categoria per n prodotti.

Es: Se vi sono 5 prodotti che appartengono alla categoria "Tessuto",
io devo specificare 5 valori per la prorietà "Colore" della categoria Tessuto, 5 valori per la prorietà "TipoTessuto", ecc... ecc...

A questo punto la relazione dovrebbe essere 1:N tra Prodotti e ls tabella ValoriProprietàCategorie.

in questo modo posso specificare un dato valore per una specifica proprietà di categoria a cui appartiene il prodotto.

Spero di aver reso anche qui il concetto... anche se mi rendo conto che la spiegazione non è del tutto chiara

ps: Alla fine vorrei ottenere una entità "Prodotto" che tramite la NavigationProperty "Proprietà" mi restituisca dei dati in forma tabellati (intendo concettualmente tabellari) con l'elenco delle proprietà (i record della tabella ValoriProprietàCategoria) e tanti record quanti sono i prodotti contenuti nella tabella aventi i rispettivi valori delle proprietà di ogni prodotto.
ops ho saltato un pezzo
CategoryProperties N:N con Categories
IDCategory
IDTypeCatProp

Products N:1 con Categories
ID
Product
IDCategory

puoi avere N Categorie con N dettagli, per ogni prodotto che appartiene alla categoria hai gli N dettagli... o almeno dovrebbe essere così

ti mando l'IBAN per la consulenza?  vabbè per stavolta te salvi, visto che non sono sicuro del risultato.

PS: cerca di fare frasi brevi e schematico nei post, con frasi lunghe è facile perdere in leggibilità, soprattutto per chi non ha il progetto ben chiaro

Non hai veramente capito qualcosa fino a quando non sei in grado di spiegarlo a tua nonna.
-Albert Einstein-
170 messaggi dal 17 febbraio 2009
fileman ha scritto:


puoi avere N Categorie con N dettagli, per ogni prodotto che appartiene alla categoria hai gli N dettagli... o almeno dovrebbe essere così


Dunque, ho analizzato meglio il problema e ho buttato giù uno schema che a mio avviso potrebbe funzionare...

Riassumo brevemente le relazioni:


Categorie - Prodotti 1:N
Categorie - ProprietàCategorie 1:N
ProprietàCategorie - ValoriProprietàProdotti 1:N
Prodotti - ValoriProprietàProdotti 1:N


riassumo la struttura che dovrebbe avere ogni tabella:


Prodotti -> |ID|NOME|CODICE|ID_CATEGORIA|
Categorie -> |ID|NOME|
ProprietàCategorie -> |ID|NOME|IDCATEGORIA|
ValoriProprietàProdotti -> |ID|VALORE|ID_PROD_CATEGORIA|ID_PRODOTTO|



Penso che di errato nella soluzione proposta da te ci sia solo la relazione N:N che in effetti consentirebbe di avere ad esempio la proprietà "Misura" disponibile sia per la categoria "Tessuto" che per la categoria "Scrivanie". Questo però potrebbe creare problemi quando associa quella tabella ai valori di ogni proprietà prodotto.
A prima vista la mia soluzione potrebbe funzionare... ma prima sarebbe meglio provarne una piccola implementazione.



ti mando l'IBAN per la consulenza?  vabbè per stavolta te salvi, visto che non sono sicuro del risultato.

PS: cerca di fare frasi brevi e schematico nei post, con frasi lunghe è facile perdere in leggibilità, soprattutto per chi non ha il progetto ben chiaro



Spero che con la soluzione proposta da me potremmo beneficiare tutti e due di questo modello

Scherzi a parte, grazie mille davvero!
con la N:N tra categorie e proprietà eviti duplicati, se "misura" è comune a tutte le categorie, non serve avere una riga per ogni categoria... secondo me

Non hai veramente capito qualcosa fino a quando non sei in grado di spiegarlo a tua nonna.
-Albert Einstein-

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.