MVC DataContext Ok per condividere una connessione o no

Question

Quando è l'unità di lavoro "quot" non è più una "unità"? Quale scenario è migliore sulle risorse? Il primo crea una connessione dove il secondo crea 4.

using (DataContext dc=new DataContext) 
{
  var orders= from o in dc.orders 
              select ( new Product {  property a= from a in ..join... select x, 
                                      property b= from b in ..join... select y,
                                      property c= from c in ..join... select z.}
                      )
}

o

using (DataContext dc=new DataContext) 
{
  var orders= from o in dc.orders 
              select ( new Product {  property a = GetPropertyA(), 
                                      property b = GetPropertyB(),
                                      property c = GetPropertyC()}
                      )
}

Answer 1

Quando si utilizza LINQ se si aggiunge un'entità a un'altra e utilizzano un contesto di dati diverso, si otterrà un errore. Suggerirei di mantenere lo stesso contesto di dati per ogni unità di lavoro che stai utilizzando. È possibile identificare facilmente l'unità di lavoro che si sta elaborando utilizzando il modello di repository per scrivere le classi di accesso ai dati. Se non sei chiaro sul modello di repository, controlla questa voce

Answer 2

In generale, meno viaggi di andata e ritorno nel database sono i migliori. Tuttavia, nelle app su larga scala spesso rendiamo i nostri database sempre più "stupidi", quindi finiamo per non fare alcun join in modo da non collegare CPU e memoria sul server di database SQL. Dipende davvero da quali risorse trovi più scarse. Se il tuo server SQL ha molte risorse fai il join lì, altrimenti sarebbe meglio tirarlo indietro separatamente. Hai esaminato i risultati di questo nel profiler SQL? Sei sicuro che siano 4 connessioni o solo 4 chiamate separate?