Ja. Pointen er kun at bruge den rigtige database til integrationstest, som ikke skal udføres så ofte, og hele sættet af integrationstest udføres normalt kun på build-serveren.
Dette er på grund af langsom initialisering af EF ved enhedstestning (du kan prøve at skifte til x86). Tiden forbruges også af visningsgenerering. Visninger kan forudgenereres hvilket normalt gøres for at reducere opstart og initialisering af det rigtige system, men i tilfælde af at fremskynde enhedstests ved hjælp af view pre-generation vil det ikke hjælpe for meget, fordi du blot vil flytte tiden fra test til build.
At gå rundt ville bare betyde at bruge almindeligt gammelt SQL-script. Den ekstra tid, der er nødvendig for denne operation, kan blive brugt på at generere denne SQL. Jeg tror, at SQL'en ikke er cachelagret, fordi normal applikationsudførelse normalt ikke har brug for det mere end én gang, men du kan bede EF om at give dig, for at den vigtigste del af SQL'en ikke skal cache den et sted og udføre den selv, hver gang du har brug for den . EF er i stand til at give dig SQL for tabeller og begrænsninger:
var dbSql = ((IObjectContextAdapter) context).ObjectContext.CreateDatabaseScript();
Du skal bare have din egen lille SQL for at oprette database og bruge dem sammen. Selv noget som følgende script burde være nok:
CREATE DATABASE YourDatabaseName
USE YourDatabaseName
Du skal også deaktivere databasegenerering i kode først for at få dette til at fungere og for at tage kontrol over processen:
Database.SetInitializer<YourContextType>(null);
Når du udfører databaseoprettelse SQL, skal du bruge en separat forbindelsesstreng, der peger på Master database.