Quando aggiungiamo file .edmx a una DLL, la dimensione fisica della DLL aumenta. Le DLL sono caricate in memoria. Tuttavia, l'infrastruttura .NET con funzionalità come la compilazione JIT e il GAC complica le cose. È vero che avere una DLL più grande aumenta automaticamente i requisiti di memoria di un'applicazione?
In altre parole, la memoria è una buona ragione per dividere il codice generato come il framework di entità in N DLL?
Ovviamente, più codice hai nell'applicazione, più memoria è necessaria per caricare tutto quel codice durante l'esecuzione dell'applicazione. Ma
In other words, are memory concerns a good reason to split generated code such as entity framework into N DLL's?
Direi di no. Il computer moderno dovrebbe avere più memoria sufficiente per caricare tutto il codice eseguibile in una sola volta. Potrebbe esserci un problema con la memoria run time, ad es. se dovessi provare a memorizzare nella cache tutti i dati per un'applicazione enterprise in memoria. Ma non il codice eseguibile, IMHO.
E dividerlo in più DLL non sarebbe di grande aiuto. Dovresti comunque caricare tutto il codice eseguibile affinché l'applicazione funzioni. Tranne se vuoi caricare / scaricare il codice su richiesta.
E provare a caricare / scaricare il codice su richiesta aggiunge ulteriore complessità al progetto. Questa complessità aggiunge costi e rischi (che è più costoso). Per esempio. non puoi semplicemente scaricare una DLL in .NET. Devi caricarlo in un AppDomain separato. Quindi puoi scaricare AppDomain.
Se si stava veramente colpendo il limite di memoria per il codice eseguibile, l'aggiornamento della memoria sui computer che eseguono l'applicazione sarebbe probabilmente più economico rispetto all'implementazione del caricamento / scaricamento del codice in fase di runtime.
Leggi altre domande sui tag c# .net memory entity-framework