Ja. Het punt is om de echte database alleen te gebruiken voor integratietests die niet zo vaak hoeven te worden uitgevoerd en de hele reeks integratietests wordt meestal alleen op de buildserver uitgevoerd.
Dit komt door langzame initialisatie van EF bij het testen van eenheden (u kunt proberen over te schakelen naar x86). De tijd wordt ook verbruikt door het genereren van weergaven. Weergaven kunnen vooraf worden gegenereerd wat meestal wordt gedaan om het opstarten en initialiseren van het echte systeem te verminderen, maar in het geval van het versnellen van unit-tests met behulp van view pre-generatie zal niet al te veel helpen, omdat je de tijd van test naar build gewoon verplaatst.
Rondgaan zou gewoon betekenen dat u gewoon oud SQL-script gebruikt. De extra tijd die voor deze bewerking nodig is, kan worden besteed aan het genereren van die SQL. Ik denk dat de SQL niet in de cache is opgeslagen omdat de normale uitvoering van de applicatie het normaal gesproken niet meer dan één keer nodig heeft, maar je kunt EF vragen om je op zijn minst het belangrijkste deel van die SQL te geven, het ergens in de cache te plaatsen en het zelf uit te voeren elke keer dat je het nodig hebt . EF kan u SQL geven voor tabellen en beperkingen:
var dbSql = ((IObjectContextAdapter) context).ObjectContext.CreateDatabaseScript();
U hoeft alleen maar uw eigen kleine SQL te hebben om een database te maken en deze samen te gebruiken. Zelfs zoiets als het volgende script zou voldoende moeten zijn:
CREATE DATABASE YourDatabaseName
USE YourDatabaseName
U moet ook eerst het genereren van databases in code uitschakelen om dit te laten werken en om controle over het proces te krijgen:
Database.SetInitializer<YourContextType>(null);
Bij het uitvoeren van SQL voor het maken van een database heeft u een aparte verbindingsreeks nodig die verwijst naar Master databank.