Biblioteka klienta elastycznej bazy danych z platformą Entity Framework

Dotyczy:Azure SQL Database

W tym dokumencie przedstawiono zmiany w aplikacji Platformy Entity Framework, które są wymagane do integracji z narzędziami elastic Database. Koncentruje się na komponowaniu zarządzania mapami fragmentów i routingu zależnego od danych przy użyciu podejścia Entity Framework Code First . Samouczek Code First — nowa baza danych dla programu EF służy jako przykład uruchamiania w tym dokumencie. Przykładowy kod towarzyszący temu dokumentowi jest częścią zestawu przykładów narzędzi elastycznej bazy danych w przykładach programu Visual Studio Code.

Uwaga

Ten artykuł nie ma zastosowania do platformy Entity Framework Core (EF Core).

Pobieranie i uruchamianie przykładowego kodu

Aby pobrać kod dla tego artykułu:

• Wymagany jest program Visual Studio 2012 lub nowszy.
• Pobierz przykład Elastic DB Tools for Azure SQL — Entity Framework Integration (Narzędzia elastic DB tools for Azure SQL — Entity Framework Integration). Rozpakuj przykład do wybranej lokalizacji.
• Uruchom program Visual Studio.
• W programie Visual Studio wybierz pozycję Plik —> otwórz projekt/rozwiązanie.
• W oknie dialogowym Otwieranie projektu przejdź do pobranego przykładu i wybierz pozycję EntityFrameworkCodeFirst.sln, aby otworzyć przykład.

Aby uruchomić przykład, musisz utworzyć trzy puste bazy danych w usłudze Azure SQL Database:

• Baza danych menedżera map fragmentów
• Baza danych fragmentu 1
• Baza danych fragmentu 2

Po utworzeniu tych baz danych wypełnij symbole zastępcze w pliku Program.cs nazwą serwera, nazwami baz danych i poświadczeniami, aby nawiązać połączenie z bazami danych. Skompiluj rozwiązanie w programie Visual Studio. Program Visual Studio pobiera wymagane pakiety NuGet dla elastycznej biblioteki klienta bazy danych, programu Entity Framework i obsługi błędów przejściowych w ramach procesu kompilacji. Upewnij się, że przywracanie pakietów NuGet jest włączone dla rozwiązania. To ustawienie można włączyć, klikając prawym przyciskiem myszy plik rozwiązania w programie Visual Studio Eksplorator rozwiązań.

Przepływy pracy programu Entity Framework

Deweloperzy programu Entity Framework korzystają z jednego z czterech następujących przepływów pracy w celu tworzenia aplikacji i zapewnienia trwałości obiektów aplikacji:

• Code First (nowa baza danych): deweloper EF tworzy model w kodzie aplikacji, a następnie program EF generuje z niej bazę danych.
• Code First (istniejąca baza danych): deweloper umożliwia programowi EF generowanie kodu aplikacji dla modelu z istniejącej bazy danych.
• Najpierw model: deweloper tworzy model w projektancie EF, a następnie program EF tworzy bazę danych na podstawie modelu.
• Najpierw baza danych: deweloper używa narzędzi EF do wnioskowania modelu z istniejącej bazy danych.

Wszystkie te podejścia opierają się na klasie DbContext, aby w sposób niewidoczny zarządzać połączeniami bazy danych i schematem bazy danych dla aplikacji. Różne konstruktory w klasie bazowej DbContext umożliwiają różne poziomy kontroli nad tworzeniem połączenia, uruchamianiem bazy danych i tworzeniem schematu. Wyzwania wynikają przede wszystkim z faktu, że zarządzanie połączeniami z bazą danych zapewniane przez program EF współdziała z możliwościami zarządzania połączeniami interfejsów routingu zależnego od danych udostępnianych przez elastyczną bibliotekę klienta bazy danych.

Założenia dotyczące narzędzi elastycznych baz danych

Aby zapoznać się z definicjami terminów, zobacz Słownik narzędzi elastycznych baz danych.

W przypadku elastycznej biblioteki klienta bazy danych należy zdefiniować partycje danych aplikacji o nazwie shardlets. Fragmenty są identyfikowane przez klucz fragmentowania i są mapowane na określone bazy danych. Aplikacja może mieć dowolną liczbę baz danych i dystrybuować podfragmenty, aby zapewnić wystarczającą pojemność lub wydajność, biorąc pod uwagę bieżące wymagania biznesowe. Mapowanie wartości klucza fragmentowania do baz danych jest przechowywane przez mapę fragmentów dostarczaną przez elastyczne interfejsy API klienta bazy danych. Ta funkcja jest nazywana zarządzanie mapami fragmentów lub SMM na krótko. Mapa fragmentów służy również jako broker połączeń bazy danych dla żądań, które mają klucz fragmentowania. Ta funkcja jest znana jako routing zależny od danych.

Menedżer map fragmentów chroni użytkowników przed niespójnymi widokami w dane fragmentów, które mogą wystąpić podczas współbieżnych operacji zarządzania fragmentami (takich jak przenoszenie danych z jednego fragmentu do innego). W tym celu fragmenty mapowane przez bibliotekę klienta brokera połączeń bazy danych dla aplikacji. Dzięki temu funkcja mapy fragmentów może automatycznie zabić połączenie bazy danych, gdy operacje zarządzania fragmentami mogą mieć wpływ na podfragment, dla którego utworzono połączenie. Takie podejście musi być zintegrowane z niektórymi funkcjami programu EF, takimi jak tworzenie nowych połączeń z istniejącego, aby sprawdzić istnienie bazy danych. Ogólnie rzecz biorąc, naszą obserwacją jest to, że standardowe konstruktory DbContext działają niezawodnie tylko w przypadku zamkniętych połączeń bazy danych, które można bezpiecznie sklonować na potrzeby pracy ef. Zamiast tego zasadą projektowania elastycznej bazy danych jest tylko broker otwartych połączeń. Można pomyśleć, że zamknięcie połączenia obsługiwanego przez bibliotekę klienta przed przekazaniem jej do programu EF DbContext może rozwiązać ten problem. Jednak zamknięcie połączenia i poleganie na programie EF w celu jego ponownego otwarcia, jedno z nich oznacza weryfikację i sprawdzanie spójności wykonywane przez bibliotekę. Funkcje migracji w programie EF używają jednak tych połączeń do zarządzania bazowym schematem bazy danych w sposób niewidoczny dla aplikacji. W idealnym przypadku zachowasz i połączysz wszystkie te możliwości zarówno z elastycznej biblioteki klienta bazy danych, jak i platformy EF w tej samej aplikacji. W poniższej sekcji omówiono te właściwości i wymagania bardziej szczegółowo.

Wymagania

Podczas pracy z biblioteką klienta elastycznej bazy danych i interfejsami API programu Entity Framework należy zachować następujące właściwości:

• Skalowanie w poziomie: aby dodać lub usunąć bazy danych z warstwy danych aplikacji podzielonej na fragmenty zgodnie z potrzebami dotyczącymi pojemności aplikacji. Oznacza to kontrolę nad tworzeniem i usuwaniem baz danych oraz używanie elastycznych interfejsów API menedżera map fragmentów bazy danych do zarządzania bazami danych i mapowania fragmentów.
• Spójność: aplikacja stosuje fragmentowanie i używa funkcji routingu zależnego od danych biblioteki klienta. Aby uniknąć uszkodzenia lub nieprawidłowych wyników zapytań, połączenia są obsługiwane za pośrednictwem menedżera mapy fragmentów. Zachowuje to również walidację i spójność.
• Najpierw kod: aby zachować wygodę pierwszego paradygmatu platformy EF. W kodzie First klasy w aplikacji są mapowane w sposób niewidoczny dla bazowych struktur bazy danych. Kod aplikacji współdziała z zestawami DbSet, które maskuje większość aspektów związanych z podstawowym przetwarzaniem bazy danych.
• Schemat: program Entity Framework obsługuje początkowe tworzenie schematu bazy danych i kolejną ewolucję schematu za pośrednictwem migracji. Dzięki zachowaniu tych możliwości dostosowanie aplikacji jest łatwe w miarę rozwoju danych.

Poniższe wskazówki zawierają instrukcje dotyczące spełnienia tych wymagań dla aplikacji Code First przy użyciu narzędzi elastycznej bazy danych.

Routing zależny od danych przy użyciu interfejsu EF DbContext

Połączenia bazy danych z programem Entity Framework są zwykle zarządzane za pośrednictwem podklas dbContext. Utwórz te podklasy, wyprowadzając je z elementu DbContext. W tym miejscu należy zdefiniować zestawy DbSet, które implementują kolekcje obiektów CLR oparte na bazie danych dla aplikacji. W kontekście routingu zależnego od danych można zidentyfikować kilka przydatnych właściwości, które nie muszą być przechowywane w innych scenariuszach aplikacji programu EF Code first:

• Baza danych już istnieje i została zarejestrowana na elastycznej mapie fragmentów bazy danych.
• Schemat aplikacji został już wdrożony w bazie danych (wyjaśniono poniżej).
• Połączenia routingu zależne od danych z bazą danych są obsługiwane przez mapę fragmentów.

Aby zintegrować element DbContexts z routingiem zależnym od danych dla skalowania w poziomie:

1. Tworzenie fizycznych połączeń bazy danych za pomocą elastycznych interfejsów klienta bazy danych menedżera map fragmentów.
2. Zawijanie połączenia z podklasą DbContext
3. Przekaż połączenie do klas bazowych DbContext , aby upewnić się, że wszystkie operacje przetwarzania po stronie ef również będą wykonywane.

Poniższy przykład kodu ilustruje to podejście. (Ten kod znajduje się również w towarzyszącym projekcie programu Visual Studio)

public class ElasticScaleContext<T> : DbContext
{
public DbSet<Blog> Blogs { get; set; }
...

    // C'tor for data-dependent routing. This call opens a validated connection
    // routed to the proper shard by the shard map manager.
    // Note that the base class c'tor call fails for an open connection
    // if migrations need to be done and SQL credentials are used. This is the reason for the
    // separation of c'tors into the data-dependent routing case (this c'tor) and the internal c'tor for new shards.
    public ElasticScaleContext(ShardMap shardMap, T shardingKey, string connectionStr)
        : base(CreateDDRConnection(shardMap, shardingKey, connectionStr),
        true /* contextOwnsConnection */)
    {
    }

    // Only static methods are allowed in calls into base class c'tors.
    private static DbConnection CreateDDRConnection(
    ShardMap shardMap,
    T shardingKey,
    string connectionStr)
    {
        // No initialization
        Database.SetInitializer<ElasticScaleContext<T>>(null);

        // Ask shard map to broker a validated connection for the given key
        SqlConnection conn = shardMap.OpenConnectionForKey<T>
                            (shardingKey, connectionStr, ConnectionOptions.Validate);
        return conn;
    }

Główne punkty

• Nowy konstruktor zastępuje konstruktor domyślny w podklasie DbContext

• Nowy konstruktor przyjmuje argumenty wymagane do routingu zależnego od danych za pośrednictwem elastycznej biblioteki klienta bazy danych:

  • mapa fragmentów w celu uzyskania dostępu do interfejsów routingu zależnego od danych,
  • klucz fragmentowania w celu zidentyfikowania podfragmentu,
  • parametry połączenia z poświadczeniami dla połączenia routingu zależnego od danych z fragmentem.

• Wywołanie konstruktora klasy bazowej przyjmuje objazd do metody statycznej, która wykonuje wszystkie kroki niezbędne do routingu zależnego od danych.

  • Używa on wywołania Open Połączenie ionForKey interfejsów klienta elastycznej bazy danych na mapie fragmentów w celu ustanowienia otwartego połączenia.
  • Mapa fragmentów tworzy otwarte połączenie z fragmentem zawierającym fragment dla danego klucza fragmentowania.
  • To otwarte połączenie jest przekazywane z powrotem do konstruktora klasy bazowej DbContext, aby wskazać, że to połączenie ma być używane przez program EF zamiast zezwalać ef na automatyczne tworzenie nowego połączenia. W ten sposób połączenie zostało oznaczone przez elastyczny interfejs API klienta bazy danych, aby zagwarantować spójność w ramach operacji zarządzania mapami fragmentów.

Użyj nowego konstruktora dla podklasy DbContext zamiast domyślnego konstruktora w kodzie. Oto przykład:

// Create and save a new blog.

Console.Write("Enter a name for a new blog: ");
var name = Console.ReadLine();

using (var db = new ElasticScaleContext<int>(
                        sharding.ShardMap,  
                        tenantId1,  
                        connStrBldr.ConnectionString))
{
    var blog = new Blog { Name = name };
    db.Blogs.Add(blog);
    db.SaveChanges();

    // Display all Blogs for tenant 1
    var query = from b in db.Blogs
                orderby b.Name
                select b;
    …
}

Nowy konstruktor otwiera połączenie z fragmentem, który przechowuje dane dla fragmentu zidentyfikowanego przez wartość tenantid1. Kod w bloku using pozostaje niezmieniony, aby uzyskać dostęp do zestawu DbSet dla blogów przy użyciu programu EF w ramach fragmentu dla identyfikatora tenantid1. Spowoduje to zmianę semantyki kodu w bloku using, tak aby wszystkie operacje bazy danych były teraz ograniczone do jednego fragmentu, w którym jest przechowywany identyfikator tenantid1 . Na przykład zapytanie LINQ w blogach DbSet zwraca tylko blogi przechowywane w bieżącym fragmentze, ale nie te przechowywane w innych fragmentach.

Obsługa błędów przejściowych

Zespół ds. wzorców i rozwiązań firmy Microsoft opublikował blok aplikacji Obsługa błędów przejściowych. Biblioteka jest używana z biblioteką klienta elastycznej skali w połączeniu z programem EF. Upewnij się jednak, że każdy wyjątek przejściowy powraca do miejsca, w którym można upewnić się, że nowy konstruktor jest używany po błędzie przejściowym, tak aby każda nowa próba połączenia została podjęta przy użyciu konstruktorów, które zostały poprawione. W przeciwnym razie połączenie z poprawnym fragmentem nie jest gwarantowane i nie ma żadnych gwarancji, że połączenie jest utrzymywane w miarę występowania zmian w mapie fragmentów.

Poniższy przykładowy kod ilustruje sposób użycia zasad ponawiania prób SQL wokół nowych konstruktorów podklasy DbContext :

SqlDatabaseUtils.SqlRetryPolicy.ExecuteAction(() =>
{
    using (var db = new ElasticScaleContext<int>(
                            sharding.ShardMap,  
                            tenantId1,  
                            connStrBldr.ConnectionString))
        {
                var blog = new Blog { Name = name };
                db.Blogs.Add(blog);
                db.SaveChanges();
        …
        }
    });

SqlDatabaseUtils.SqlRetryPolicy w powyższym kodzie jest definiowany jako sqlDatabaseTransientErrorDetectionStrategy z liczbą ponownych prób wynoszącą 10 i 5 sekund oczekiwania między ponownymi próbami. Takie podejście jest podobne do wskazówek dotyczących transakcji ef i transakcji inicjowanych przez użytkownika (zobacz Ograniczenia dotyczące strategii ponawiania prób wykonania (EF6). Obie sytuacje wymagają, aby program aplikacji kontroluje zakres, do którego zwraca wyjątek przejściowy: ponowne otwarcie transakcji lub (jak pokazano) ponowne utworzenie kontekstu z odpowiedniego konstruktora używającego elastycznej biblioteki klienta bazy danych.

Konieczność kontrolowania sytuacji, w której wyjątki przejściowe wracają do zakresu, również wyklucza użycie wbudowanej klasy SqlAzureExecutionStrategy dostarczanej z platformą EF. SqlAzureExecutionStrategy ponownie otworzy połączenie, ale nie użyje polecenia Open Połączenie ionForKey i w związku z tym pomiń całą walidację wykonywaną w ramach wywołania Open Połączenie ionForKey. Zamiast tego przykładowy kod używa wbudowanej klasy DefaultExecutionStrategy , która jest również dostarczana z platformą EF. W przeciwieństwie do sqlAzureExecutionStrategy, działa poprawnie w połączeniu z zasadami ponawiania z obsługi błędów przejściowych. Zasady wykonywania są ustawiane w klasie ElasticScaleDbConfiguration . Pamiętaj, że postanowiliśmy nie używać wartości DefaultSqlExecutionStrategy , ponieważ sugeruje użycie klasy SqlAzureExecutionStrategy w przypadku wystąpienia przejściowych wyjątków , co doprowadziłoby do błędnego zachowania zgodnie z opisem. Aby uzyskać więcej informacji na temat różnych zasad ponawiania prób i programu EF, zobacz Połączenie odporność na odporność w programie EF.

Ponowne zapisywanie konstruktorów

Powyższe przykłady kodu ilustrują domyślne operacje ponownego zapisu konstruktora wymagane dla aplikacji w celu korzystania z routingu zależnego od danych z platformą Entity Framework. Poniższa tabela uogólnia to podejście do innych konstruktorów.

Bieżący konstruktor	Przepisany konstruktor dla danych	Konstruktor podstawowy	Uwagi
MyContext()	ElasticScaleContext(ShardMap, TKey)	DbContext(Db Połączenie ion, bool)	Połączenie musi być funkcją mapy fragmentów i kluczem routingu zależnego od danych. Należy przekazać automatyczne tworzenie połączenia przez program EF i zamiast tego użyć mapy fragmentów do brokera połączenia.
MyContext(ciąg)	ElasticScaleContext(ShardMap, TKey)	DbContext(Db Połączenie ion, bool)	Połączenie jest funkcją mapy fragmentów i kluczem routingu zależnego od danych. Stała nazwa bazy danych lub parametry połączenia nie działa w miarę ich przekazywania przez mapę fragmentów.
MyContext(DbCompiledModel)	ElasticScaleContext(ShardMap, TKey, DbCompiledModel)	DbContext(Db Połączenie ion, DbCompiledModel, bool)	Połączenie zostanie utworzone dla podanej mapy fragmentu i klucza fragmentowania z udostępnionym modelem. Skompilowany model jest przekazywany do konstruktora podstawowego.
MyContext(Db Połączenie ion, bool)	ElasticScaleContext(ShardMap, TKey, bool)	DbContext(Db Połączenie ion, bool)	Połączenie musi zostać wywnioskowane z mapy fragmentów i klucza. Nie można go podać jako danych wejściowych (chyba że dane wejściowe używały już mapy fragmentów i klucza). Wartość logiczna jest przekazywana.
MyContext(ciąg, DbCompiledModel)	ElasticScaleContext(ShardMap, TKey, DbCompiledModel)	DbContext(Db Połączenie ion, DbCompiledModel, bool)	Połączenie musi zostać wywnioskowane z mapy fragmentów i klucza. Nie można go podać jako danych wejściowych (chyba że dane wejściowe używały mapy fragmentów i klucza). Skompilowany model jest przekazywany.
MyContext(ObjectContext, bool)	ElasticScaleContext(ShardMap, TKey, ObjectContext, bool)	DbContext(ObjectContext, bool)	Nowy konstruktor musi upewnić się, że każde połączenie w obiekcieContext przekazane jako dane wejściowe jest ponownie kierowane do połączenia zarządzanego przez usługę Elastic Scale. Szczegółowa dyskusja na temat obiektuContexts wykracza poza zakres tego dokumentu.
MyContext(Db Połączenie ion, DbCompiledModel, bool)	ElasticScaleContext(ShardMap, TKey, DbCompiledModel, bool)	DbContext(Db Połączenie ion, DbCompiledModel, bool);	Połączenie musi zostać wywnioskowane z mapy fragmentów i klucza. Nie można podać połączenia jako danych wejściowych (chyba że dane wejściowe były już używane przy użyciu mapy fragmentów i klucza). Model i wartość logiczna są przekazywane do konstruktora klasy bazowej.

Wdrażanie schematu fragmentu za pośrednictwem migracji ef

Automatyczne zarządzanie schematami jest wygodą zapewnianą przez program Entity Framework. W kontekście aplikacji korzystających z narzędzi elastycznej bazy danych chcesz zachować tę możliwość, aby automatycznie aprowizować schemat do nowo utworzonych fragmentów, gdy bazy danych są dodawane do aplikacji podzielonej na fragmenty. Podstawowym przypadkiem użycia jest zwiększenie pojemności w warstwie danych dla aplikacji podzielonych na fragmenty przy użyciu programu EF. Poleganie na możliwościach programu EF do zarządzania schematami zmniejsza nakład pracy administratora bazy danych przy użyciu aplikacji podzielonej na fragmenty utworzonej na platformie EF.

Wdrażanie schematu za pośrednictwem migracji ef działa najlepiej w przypadku nieotwartych połączeń. Jest to w przeciwieństwie do scenariusza routingu zależnego od danych, który opiera się na otwartym połączeniu udostępnianym przez elastyczny interfejs API klienta bazy danych. Inną różnicą jest wymaganie spójności: chociaż pożądane jest zapewnienie spójności dla wszystkich połączeń routingu zależnego od danych w celu ochrony przed równoczesną manipulacją mapą fragmentów, nie jest to problem z początkowym wdrożeniem schematu w nowej bazie danych, która nie została jeszcze zarejestrowana na mapie fragmentów, a nie została jeszcze przydzielona do przechowywania fragmentów. W związku z tym można polegać na regularnych połączeniach bazy danych w tym scenariuszu, w przeciwieństwie do routingu zależnego od danych.

Prowadzi to do podejścia, w którym wdrożenie schematu za pośrednictwem migracji ef jest ściśle powiązane z rejestracją nowej bazy danych jako fragmentem na mapie fragmentu aplikacji. Jest to zależne od następujących wymagań wstępnych:

• Baza danych została już utworzona.
• Baza danych jest pusta — nie zawiera schematu użytkownika i danych użytkownika.
• Nie można jeszcze uzyskać dostępu do bazy danych za pośrednictwem elastycznych interfejsów API klienta bazy danych na potrzeby routingu zależnego od danych.

Korzystając z tych wymagań wstępnych, można utworzyć regularne nieotwarte rozszerzenie Sql Połączenie ion, aby rozpocząć migracje ef na potrzeby wdrażania schematu. Poniższy przykładowy kod ilustruje to podejście.

// Enter a new shard - i.e. an empty database - to the shard map, allocate a first tenant to it  
// and kick off EF initialization of the database to deploy schema

public void RegisterNewShard(string server, string database, string connStr, int key)
{

    Shard shard = this.ShardMap.CreateShard(new ShardLocation(server, database));

    SqlConnectionStringBuilder connStrBldr = new SqlConnectionStringBuilder(connStr);
    connStrBldr.DataSource = server;
    connStrBldr.InitialCatalog = database;

    // Go into a DbContext to trigger migrations and schema deployment for the new shard.
    // This requires an un-opened connection.
    using (var db = new ElasticScaleContext<int>(connStrBldr.ConnectionString))
    {
        // Run a query to engage EF migrations
        (from b in db.Blogs
            select b).Count();
    }

    // Register the mapping of the tenant to the shard in the shard map.
    // After this step, data-dependent routing on the shard map can be used

    this.ShardMap.CreatePointMapping(key, shard);
}

W tym przykładzie przedstawiono metodę RegisterNewShard , która rejestruje fragment na mapie fragmentu, wdraża schemat za pośrednictwem migracji ef i przechowuje mapowanie klucza fragmentowania do fragmentu. Opiera się on na konstruktorze podklasy DbContext (ElasticScaleContext w przykładzie), który przyjmuje parametry połączenia SQL jako dane wejściowe. Kod tego konstruktora jest prosty, jak pokazano w poniższym przykładzie:

// C'tor to deploy schema and migrations to a new shard
protected internal ElasticScaleContext(string connectionString)
    : base(SetInitializerForConnection(connectionString))
{
}

// Only static methods are allowed in calls into base class c'tors
private static string SetInitializerForConnection(string connectionString)
{
    // You want existence checks so that the schema can get deployed
    Database.SetInitializer<ElasticScaleContext<T>>(
new CreateDatabaseIfNotExists<ElasticScaleContext<T>>());

    return connectionString;
}

Można użyć wersji konstruktora dziedziczonej z klasy bazowej. Jednak kod musi upewnić się, że domyślny inicjator ef jest używany podczas nawiązywania połączenia. Dlatego krótkie objazd do metody statycznej przed wywołaniem do konstruktora klasy bazowej za pomocą parametry połączenia. Należy pamiętać, że rejestracja fragmentów powinna być uruchamiana w innej domenie lub procesie aplikacji, aby upewnić się, że ustawienia inicjatora dla programu EF nie powodują konfliktu.

Ograniczenia

Podejścia opisane w tym dokumencie wiążą się z kilkoma ograniczeniami:

• Aplikacje EF korzystające z bazy danych LocalDb najpierw muszą przeprowadzić migrację do regularnej bazy danych programu SQL Server przed użyciem elastycznej biblioteki klienta bazy danych. Skalowanie aplikacji w poziomie za pomocą fragmentowania za pomocą elastycznej skali nie jest możliwe w przypadku bazy danych LocalDb. Należy pamiętać, że programowanie nadal może używać bazy danych LocalDb.
• Wszelkie zmiany w aplikacji, które sugerują zmiany schematu bazy danych, muszą przejść przez migracje ef we wszystkich fragmentach. Przykładowy kod tego dokumentu nie pokazuje, jak to zrobić. Rozważ użycie parametru Update-Database z parametrem Połączenie ionString w celu iteracji we wszystkich fragmentach; lub wyodrębnij skrypt T-SQL do oczekującej migracji przy użyciu opcji -Script i zastosuj skrypt języka T-SQL do fragmentów.
• Biorąc pod uwagę żądanie, zakłada się, że wszystkie jego przetwarzanie bazy danych znajduje się w jednym fragmentze zidentyfikowanym przez klucz fragmentowania dostarczony przez żądanie. Jednak to założenie nie zawsze jest prawdziwe. Jeśli na przykład nie można udostępnić klucza fragmentowania. Aby rozwiązać ten problem, biblioteka klienta udostępnia klasę MultiShardQuery , która implementuje abstrakcję połączenia na potrzeby wykonywania zapytań względem kilku fragmentów. Edukacja do korzystania z Funkcja MultiShardQuery w połączeniu z programem EF wykracza poza zakres tego dokumentu

Podsumowanie

W ramach kroków opisanych w tym dokumencie aplikacje EF mogą korzystać z możliwości elastycznej biblioteki klienta bazy danych na potrzeby routingu zależnego od danych przez refaktoryzację konstruktorów podklas DbContext używanych w aplikacji EF. Ogranicza to zmiany wymagane do tych miejsc, w których już istnieją klasy DbContext . Ponadto aplikacje EF mogą nadal korzystać z automatycznego wdrażania schematu, łącząc kroki, które wywołują niezbędne migracje ef z rejestracją nowych fragmentów i mapowań na mapie fragmentów.

Dodatkowe zasoby

Jeszcze nie korzystasz z narzędzi elastycznych baz danych? Zapoznaj się z naszym przewodnikiem Wprowadzenie. W przypadku pytań skontaktuj się z nami na stronie pytań i odpowiedzi dotyczących usługi SQL Database oraz w przypadku żądań funkcji, dodaj nowe pomysły lub zagłosuj na istniejące pomysły na forum opinii usługi SQL Database.