TAk. Chodzi o to, aby z prawdziwej bazy danych korzystać tylko do testów integracyjnych, które nie muszą być wykonywane tak często, a cały zestaw testów integracyjnych jest zwykle wykonywany tylko na serwerze budującym.
Dzieje się tak z powodu wolna inicjalizacja EF podczas testów jednostkowych (możesz spróbować przełączyć się na x86). Czas pochłania również generowanie widoków. Widoki można wstępnie wygenerować co zwykle ma na celu skrócenie uruchamiania i inicjalizacji rzeczywistego systemu, ale w przypadku przyspieszenia testów jednostkowych przy użyciu wstępnego generowania widoku nie pomoże zbytnio, ponieważ po prostu przesuniesz czas od testu do kompilacji.
Poruszanie się oznaczałoby po prostu używanie zwykłego starego skryptu SQL. Dodatkowy czas potrzebny na tę operację można poświęcić na wygenerowanie tego kodu SQL. Myślę, że SQL nie jest buforowany, ponieważ normalne wykonanie aplikacji zwykle nie wymaga go więcej niż raz, ale możesz poprosić EF, aby dał ci przynajmniej najważniejszą część tego SQL, buforuj go gdzieś i uruchamiaj go samodzielnie za każdym razem, gdy tego potrzebujesz . EF jest w stanie podać kod SQL dla tabel i ograniczeń:
var dbSql = ((IObjectContextAdapter) context).ObjectContext.CreateDatabaseScript();
Wystarczy mieć swój własny mały SQL, aby stworzyć bazę danych i używać ich razem. Nawet coś takiego jak poniższy skrypt powinno wystarczyć:
CREATE DATABASE YourDatabaseName
USE YourDatabaseName
Musisz również najpierw wyłączyć generowanie bazy danych w kodzie, aby to zadziałało i przejąć kontrolę nad procesem:
Database.SetInitializer<YourContextType>(null);
Podczas wykonywania SQL tworzenia bazy danych będziesz potrzebować oddzielnego ciągu połączenia wskazującego na Master Baza danych.
