imho no, non può essere un caso reale. perchè è raro che aggiungi 100 elementi del genere, visto che avrai sicuramente più complessità. ed è indubbio che se usi un ORM/comunque-tu-voglia-chiamare-EF-e-L2Q, lo fai per avere una maggiore comodità (e minore complessità e meno codice di plumbing intorno) e non per avere migliori performance, perchè quelle è ovvio che potendo decidere tu esattamente come implementare il codice, riesci a trovarle affinando il più possibile. cmq, è interessante

Daniele Bochicchio | ASPItalia.com | Libri
Chief Operating Officer@iCubed
Microsoft Regional Director & MVP
3.121 messaggi dal 29 ottobre 2001
Contributi | Blog
Solo un pazzo farebbe un inserimento di quel genere con Linq e l'EF

Il mio è stato solo un test molto forzato per vedere le differenze sostanziali tra le due tecnologie Linq to Sql e l'Entity Framework per capire il comportamento di entrambe (volevo vedere le differenze anche a livello di query eseguite sul db). Avevo immaginato, anche leggendo altri blog, che l'EF fosse più efficiente, ma non una differenza così marcata. E probabilmente con entità più complesse le differenze aumenterebbero ancora

Però si è capito che mi piace l'Entity framework

Ciao
Avevo letto che EF fosse più performante di LINQ to SQL in fase di modifica, ma sarei curioso se nelle query il profiler ti mostra che effettivamente il tempo di esecuzione è diverso o se la differenza è talmente minima che le prestazioni sono più da inputare a codice .NET.
Se non erro però in fase di select LINQ to SQL è più veloce di EF per via della minore complessità. Confermi?

Ciao

Il mio blog
Homepage
3.121 messaggi dal 29 ottobre 2001
Contributi | Blog
Ciao,
ho fatto ora delle prove. La cosa che mi aveva lasciato il primo dubbio era il diverso modo di avere l'Id dell'ultimo inserimento da parte delle due tecnologie. Ho fatto dei banali test (grossi inserimenti di dati con prelievo dell'ultimo id) sia con il metodo di Linq:
INSERT INTO ...; SELECT CONVERT(Int,SCOPE_IDENTITY()) AS [value]

Che quello dell'Entity Framework:
INSERT INTO ...; select [Id] from [dbo].[Padri] where @@ROWCOUNT > 0 and [Id] = scope_identity()

E il codice SQL di Linq è migliore. Con 10.000 inserimenti, Linq si è fermato dopo 5.47 secondi, l'Entity Framework dopo 6.20 secondi. Quindi le differenze in meglio dell'Entity Framework sono da imputare al suo ottimo codice .net che nelle conversioni varie è più prestazionale di Linq to Sql.

Infine ho fatto il test per prelevare tutti i record appena inseriti. Con Linq ho usato questo codice:
         using (DataClassesDataContext dc = new DataClassesDataContext())  
        {  
            System.Data.Linq.DataLoadOptions options=new System.Data.Linq.DataLoadOptions();  
            options.LoadWith<Padri>(p=>p.Figlis);  
            dc.LoadOptions=options;  
            var coll = (from c in dc.Padris  
                       select c).ToArray<Padri>();  
        }  

Che recupera tutti i dati con questo comando SQL:
SELECT [t0].[Id], [t0].[NomePadre], [t1].[Id] AS [Id2], [t1].[IdPadre], [t1].[NomeFiglio], (  
    SELECT COUNT(*)  
    FROM [dbo].[Figli] AS [t2]  
    WHERE [t2].[IdPadre] = [t0].[Id]  
    ) AS [value]  
FROM [dbo].[Padri] AS [t0]  
LEFT OUTER JOIN [dbo].[Figli] AS [t1] ON [t1].[IdPadre] = [t0].[Id]  
ORDER BY [t0].[Id], [t1].[Id]

Con l'Entity Framework, invece, ho usato questo codice:
        using (TestEntitiesModelBenchmark.TestEntitiesEntities context = new TestEntitiesModelBenchmark.TestEntitiesEntities())  
        {  
            var coll = (from p in context.Padri.Include("Figli")  
                        select p).ToArray<TestEntitiesModelBenchmark.Padri>();  
        }  

Che richiede i dati con questo comando SQL:
SELECT   
[Project1].[Id] AS [Id],   
[Project1].[NomePadre] AS [NomePadre],   
[Project1].[C1] AS [C1],   
[Project1].[C3] AS [C2],   
[Project1].[C2] AS [C3],   
[Project1].[Id1] AS [Id1],   
[Project1].[NomeFiglio] AS [NomeFiglio],   
[Project1].[IdPadre] AS [IdPadre]  
FROM ( SELECT   
  [Extent1].[Id] AS [Id],   
  [Extent1].[NomePadre] AS [NomePadre],   
  1 AS [C1],   
  [Extent2].[Id] AS [Id1],   
  [Extent2].[IdPadre] AS [IdPadre],   
  [Extent2].[NomeFiglio] AS [NomeFiglio],   
  CASE WHEN ([Extent2].[Id] IS NULL) THEN CAST(NULL AS int) ELSE 1 END AS [C2],   
  CASE WHEN ([Extent2].[Id] IS NULL) THEN CAST(NULL AS int) ELSE 1 END AS [C3]  
  FROM  [dbo].[Padri] AS [Extent1]  
  LEFT OUTER JOIN [dbo].[Figli] AS [Extent2] ON [Extent1].[Id] = [Extent2].[IdPadre]  
)  AS [Project1]  
ORDER BY [Project1].[Id] ASC, [Project1].[C3] ASC

I tempi? Linq più veloce: 0.19s contro i 0.77s dell'Entity Framework. Però non so se questo divario e proporzionale o inversamente proporziale alla complessità dell'entità.

Ciao
Modificato da andrewz il 24 agosto 2008 19.22 -
8 messaggi dal 07 agosto 2006
provate con ADO Classico... farà secondo dopo la stored.
Questo la dice lunga sul casino che sta facendo Microsoft
3.121 messaggi dal 29 ottobre 2001
Contributi | Blog
giorgio.novello ha scritto:
provate con ADO Classico... farà secondo dopo la stored.
Questo la dice lunga sul casino che sta facendo Microsoft


Ma si parla sempre di accesso diretto al db se non usi il recordset. Come il DataSet e i suoi automatisti, ho letto che le prende da tutti e tre i sistemi. Ma non ho fatto prove in merito, perché non utilizzeri il DataSet o il RecordSet neanche se fossero 10 volte più veloce delle SP.

Ciao
Ma non ho fatto prove in merito, perché non utilizzeri il DataSet o il RecordSet neanche se fossero 10 volte più veloce delle SP.


Io sì

Comunque è giusto vedere come sono i tempi con ADO.NET direttamente ma il paragone è improprio visto che L2S e L2E alla fine usano sempre ADO.NET. Sono uno strato in più...

Ciao

Il mio blog
Homepage
3.121 messaggi dal 29 ottobre 2001
Contributi | Blog
Ricciolo wrote:
Io sì

Visti i benchmark del DataSet non c'è questo rischio

Ciao
.

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.