Rugalmas adatbázis-ügyfélkódtár az Entity Framework használatával

  • Cikk

A következőre vonatkozik: Azure SQL Database

Ez a dokumentum egy Entity Framework-alkalmazás azon módosításait mutatja be, amelyek az Elastic Database-eszközökkel való integrációhoz szükségesek. A fókusz a szegmenstérkép-kezelés és az adatfüggő útválasztás összeállítása az Entity Framework Code First megközelítésével. Az EF Kód első – Új adatbázis oktatóanyaga a jelen dokumentumban futó példaként szolgál. A dokumentumot kísérő mintakód a Rugalmas Adatbázis-eszközök Visual Studio Code-mintákban található mintáinak része.

Megjegyzés:

Ez a cikk nem alkalmazható az Entity Framework Core (EF Core) szolgáltatásra.

A mintakód letöltése és futtatása

A cikk kódjának letöltése:

  • Visual Studio 2012 vagy újabb verzióra van szükség.
  • Töltse le az Elastic DB Tools for Azure SQL – Entity Framework Integration mintát. Bontsa ki a mintát egy kiválasztott helyre.
  • Indítsa el a Visual Studiót.
  • A Visual Studióban válassza a Fájl –> Projekt/megoldás megnyitása lehetőséget.
  • A Projekt megnyitása párbeszédpanelen keresse meg a letöltött mintát, és válassza az EntityFrameworkCodeFirst.sln lehetőséget a minta megnyitásához.

A minta futtatásához három üres adatbázist kell létrehoznia az Azure SQL Database-ben:

  • Shard Map Manager-adatbázis
  • Shard 1 adatbázis
  • Shard 2 adatbázis

Miután létrehozta ezeket az adatbázisokat, töltse ki a Program.cs helyőrzőit a kiszolgáló nevével, az adatbázisnevekkel és a hitelesítő adataival az adatbázisokhoz való csatlakozáshoz. Hozza létre a megoldást a Visual Studióban. A Visual Studio a buildelési folyamat részeként letölti a rugalmas adatbázis-ügyfélkódtárhoz, az Entity Frameworkhez és az átmeneti hibakezeléshez szükséges NuGet-csomagokat. Győződjön meg arról, hogy a NuGet-csomagok visszaállítása engedélyezve van a megoldáshoz. Ezt a beállítást úgy engedélyezheti, ha a jobb gombbal a Visual Studio Megoldáskezelő megoldásfájljára kattint.

Entity Framework-munkafolyamatok

Az Entity Framework fejlesztői az alábbi négy munkafolyamat egyikére támaszkodnak az alkalmazások létrehozásához és az alkalmazásobjektumok megőrzésének biztosításához:

  • Code First (New Database): Az EF fejlesztője létrehozza a modellt az alkalmazáskódban, majd az EF létrehozza az adatbázist belőle.
  • Első kód (meglévő adatbázis):: A fejlesztő lehetővé teszi, hogy az EF egy meglévő adatbázisból hozza létre a modell alkalmazáskódját.
  • Első modell: A fejlesztő létrehozza a modellt az EF-tervezőben, majd az EF létrehozza az adatbázist a modellből.
  • Adatbázis: A fejlesztő EF-eszközök használatával következtet a modellre egy meglévő adatbázisból.

Ezek a megközelítések a DbContext osztályra támaszkodnak az alkalmazások adatbázis-kapcsolatainak és adatbázissémáinak transzparens kezelésére. A DbContext alaposztály különböző konstruktorai lehetővé teszik a kapcsolatlétrehozás, az adatbázis-rendszerindítás és a sémalétrehozás különböző szintű vezérlését. A kihívások elsősorban abból adódnak, hogy az EF által biztosított adatbázis-kapcsolatkezelés a rugalmas adatbázis-ügyfélkódtár által biztosított adatfüggő útválasztási adapterek kapcsolatkezelési képességeivel metszi egymást.

Rugalmas adatbázis-eszközökkel kapcsolatos feltételezések

A kifejezésdefiníciókért lásd az Elastic Database tools szószedetét.

Rugalmas adatbázis-ügyfélkódtár használatával definiálhatja az alkalmazásadatok partícióit, úgynevezett shardleteket. A szegmenseket egy skálázási kulcs azonosítja, és meghatározott adatbázisokra van leképezve. Előfordulhat, hogy egy alkalmazás annyi adatbázissal rendelkezik, amennyi szükséges, és elosztja a szegmenseket, hogy a jelenlegi üzleti követelményeknek megfelelően elegendő kapacitást vagy teljesítményt nyújtson. A horizontálisan skálázási kulcsértékek adatbázisokhoz való leképezését a rugalmas adatbázis-ügyfél API-k által biztosított szegmenstérkép tárolja. Ezt a képességet Shard Map Managementnek vagy röviden SMM-nek nevezzük. A szegmenstérkép adatbázis-kapcsolatok közvetítőjeként is szolgál a szilánkkulcsot tartalmazó kérések esetében. Ezt a képességet adatfüggő útválasztásnak nevezzük.

A szegmenstérkép-kezelő megvédi a felhasználókat az inkonzisztens nézetektől olyan szegmensadatokká, amelyek akkor fordulhatnak elő, ha egyidejű shardletkezelési műveletek (például adatok áthelyezése egy szegmensből egy másikba) történnek. Ehhez az ügyfélkódtár által felügyelt szegmensek leképezik az alkalmazás adatbázis-kapcsolatait. Ez lehetővé teszi, hogy a szegmenstérkép funkciói automatikusan megöljenek egy adatbázis-kapcsolatot, ha a szegmenskezelési műveletek hatással lehetnek a kapcsolat által létrehozott szegmensre. Ennek a megközelítésnek integrálnia kell az EF egyes funkcióit, például új kapcsolatokat kell létrehoznia egy meglévőből az adatbázis meglétének ellenőrzéséhez. Általánosságban elmondható, hogy a standard DbContext konstruktorok csak olyan zárt adatbázis-kapcsolatokon működnek megbízhatóan, amelyek biztonságosan klónoztak EF-munkához. A rugalmas adatbázis tervezési elve ehelyett csak a megnyitott kapcsolatok közvetítése. Azt gondolhatnánk, hogy az ügyfélkódtár által közvetített kapcsolat bezárása, mielőtt átadnánk az EF DbContextnek, megoldhatja ezt a problémát. Ha azonban bezárja a kapcsolatot, és az EF-ra támaszkodik az újbóli megnyitásához, az egyik lemond a kódtár által végrehajtott érvényesítési és konzisztencia-ellenőrzésekről. Az EF migrálási funkciója azonban ezeket a kapcsolatokat használja az alapul szolgáló adatbázisséma az alkalmazás számára transzparens módon történő kezelésére. Ideális esetben megtarthatja és kombinálhatja ezeket a képességeket mind a rugalmas adatbázis-ügyfélkódtárból, mind az EF-ből ugyanabban az alkalmazásban. A következő szakasz részletesebben ismerteti ezeket a tulajdonságokat és követelményeket.

Requirements

A rugalmas adatbázis-ügyfélkódtár és az Entity Framework API-k használatakor a következő tulajdonságokat kell megőriznie:

  • Horizontális felskálázás: Adatbázisok hozzáadása vagy eltávolítása a horizontálisan tagolt alkalmazás adatrétegéből, szükség szerint az alkalmazás kapacitásigényéhez. Ez azt jelenti, hogy szabályozható az adatbázisok létrehozása és törlése, valamint a rugalmas adatbázis-szegmensleképezési kezelő API-k használata az adatbázisok és a szegmensek leképezéseinek kezeléséhez.
  • Konzisztencia: Az alkalmazás horizontális skálázást alkalmaz, és az ügyfélkódtár adatfüggő útválasztási képességeit használja. A sérülés vagy a helytelen lekérdezési eredmények elkerülése érdekében a rendszer a szegmenstérkép-kezelőn keresztül közvetíti a kapcsolatokat. Ez megőrzi az ellenőrzést és a konzisztenciát is.
  • Első kód: Az EF kód első paradigmája kényelmének megőrzése. A Code First alkalmazásban az alkalmazás osztályai transzparensen vannak leképezve az alapul szolgáló adatbázis-struktúrákra. Az alkalmazáskód olyan dbSetekkel dolgozik, amelyek a mögöttes adatbázis feldolgozásának legtöbb aspektusát elfedik.
  • Séma: Az Entity Framework a kezdeti adatbázisséma létrehozását és az azt követő sémafejlődést kezeli migrálásokon keresztül. Ezeknek a képességeknek a megtartásával az alkalmazás könnyen adaptálható, ahogy az adatok fejlődnek.

Az alábbi útmutató bemutatja, hogyan lehet megfelelni ezeknek a követelményeknek a rugalmas adatbázis-eszközök használatával a Code First-alkalmazásokra vonatkozóan.

Adatfüggő útválasztás EF DbContext használatával

Az Entity Framework adatbázis-kapcsolatait általában a DbContext alosztályai kezelik. Ezeket az alosztályokat a DbContextből származtatva hozhatja létre. Itt határozhatja meg azokat a DBSeteket , amelyek az alkalmazás CLR-objektumainak adatbázis által támogatott gyűjteményeit implementálják. Az adatfüggő útválasztás kontextusában számos hasznos tulajdonságot azonosíthat, amelyek nem feltétlenül rendelkeznek más EF-kód első alkalmazásforgatókönyvekkel:

  • Az adatbázis már létezik, és regisztrálva lett a rugalmas adatbázis-szegmenstérképen.
  • Az alkalmazás sémája már üzembe lett helyezve az adatbázisban (az alábbiakban ismertetjük).
  • Az adatbázis adatfüggő útválasztási kapcsolatait a szegmenstérkép közvetíti.

A DbContexts integrálása adatfüggő útválasztással a vertikális felskálázáshoz:

  1. Fizikai adatbázis-kapcsolatokat hozhat létre a szegmenstérkép-kezelő rugalmas adatbázis-ügyfélfelületén keresztül.
  2. A kapcsolat körbefuttatása a DbContext alosztályral
  3. Adja át a kapcsolatot a DbContext alaposztályainak, hogy az EF-oldalon is minden feldolgozás végbemegy.

Az alábbi példakód ezt a megközelítést szemlélteti. (Ez a kód a kapcsolódó Visual Studio-projektben is szerepel)

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;
    }

Főbb pontok

  • Egy új konstruktor helyettesíti az alapértelmezett konstruktort a DbContext alosztályban

  • Az új konstruktor az adatfüggő útválasztáshoz szükséges argumentumokat veszi át rugalmas adatbázis-ügyfélkódtáron keresztül:

    • a szegmenstérkép az adatfüggő útválasztási felületek eléréséhez,
    • a szegmenskulcsot a szegmens azonosításához,
    • egy kapcsolati sztring az adatfüggő útválasztási kapcsolat hitelesítő adataival a szegmenshez.

  • Az alaposztály-konstruktor hívása egy statikus metódusba kerül, amely végrehajtja az adatfüggő útválasztáshoz szükséges összes lépést.

    • A szegmenstérkép rugalmas adatbázis-ügyfélfelületeinek Open Csatlakozás ionForKey hívásával hoz létre nyílt kapcsolatot.
    • A szegmenstérkép létrehozza a nyitott kapcsolatot a szegmenshez, amely az adott szegmenskulcshoz tartozó szegmenst tartalmazza.
    • Ez a nyitott kapcsolat visszakerül a DbContext alaposztály-konstruktorának, amely jelzi, hogy ezt a kapcsolatot az EF használja ahelyett, hogy lehetővé teszi az EF számára, hogy automatikusan hozzon létre új kapcsolatot. Így a rugalmas adatbázis-ügyfél API címkézte meg a kapcsolatot, hogy garantálhassa a szegmenstérkép-kezelési műveletek konzisztenciáját.

Használja az új konstruktort a DbContext alosztályhoz a kód alapértelmezett konstruktora helyett. Here is an example:

// 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;
    …
}

Az új konstruktor megnyitja a kapcsolatot a szegmenssel, amely a tenantid1 érték által azonosított szegmens adatait tárolja. A használatban lévő kód változatlan marad, hogy hozzáférjen a dbSethez az EF-t használó blogokhoz a tenantid1 szegmensen. Ez módosítja a kód szemantikáját a használatblokkban, így az összes adatbázis-művelet hatóköre arra a szegmensre terjed ki, amelyben a tenantid1 található. Egy LINQ-lekérdezés például a blogok adatbázisán keresztül csak az aktuális szegmensben tárolt blogokat adja vissza, a többi szegmensben tároltakat azonban nem.

Átmeneti hibák kezelése

A Microsoft Patterns & Practices csapata közzétette az Átmeneti hibakezelési alkalmazásblokkot. A kódtár rugalmas skálázású ügyféloldali kódtárakkal és EF-vel kombinálva használható. Ügyeljen azonban arra, hogy az átmeneti kivételek olyan helyre térjenek vissza, ahol biztosítható, hogy az új konstruktort átmeneti hiba után használja a rendszer, hogy minden új csatlakozási kísérlet az Ön által finomított konstruktorokkal történjen. Ellenkező esetben a megfelelő szegmenshez való csatlakozás nem garantált, és a rendszer nem garantálja, hogy a kapcsolat a szegmenstérkép módosításakor megmarad.

Az alábbi kódminta bemutatja, hogyan használható egy SQL-újrapróbálkozési szabályzat az új DbContext alosztály-konstruktorok köré:

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();
        …
        }
    });

Az SqlDatabaseUtils.SqlRetryPolicy a fenti kódban sqlDatabaseTransientErrorDetectionStrategy néven van definiálva, amelynek újrapróbálkozási száma 10, és 5 másodperc várakozási idő az újrapróbálkozások között. Ez a megközelítés hasonló az EF és a felhasználó által kezdeményezett tranzakciókra vonatkozó útmutatáshoz (lásd: Korlátozások újrapróbálkozási végrehajtási stratégiákkal (EF6-tól kezdve). Mindkét helyzet megköveteli, hogy az alkalmazásprogram szabályozza azt a hatókört, amelyre az átmeneti kivétel visszatér: vagy nyissa meg újra a tranzakciót, vagy (az ábrán látható módon) hozza létre újra a környezetet a rugalmas adatbázis-ügyfélkódtárat használó megfelelő konstruktorból.

Az átmeneti kivételek hatókörbe való visszavételének szükségessége szintén kizárja az EF-hez tartozó beépített SqlAzureExecutionStrategy használatát. Az SqlAzureExecutionStrategy újra megnyitja a kapcsolatot, de nem használja az Open Csatlakozás ionForKey parancsot, ezért megkerüli a Megnyitás Csatlakozás ionForKey hívás részeként végrehajtott összes ellenőrzést. Ehelyett a kódminta a beépített DefaultExecutionStrategyet használja, amely szintén az EF-hez tartozik. Az SqlAzureExecutionStrategy helyett az átmeneti hibakezelés újrapróbálkozási szabályzatával együtt működik megfelelően. A végrehajtási szabályzat az ElasticScaleDbConfiguration osztályban van beállítva. Vegye figyelembe, hogy úgy döntöttünk, hogy nem használjuk a DefaultSqlExecutionStrategy függvényt, mivel az sqlAzureExecutionStrategy használatát javasolja átmeneti kivételek esetén – ami a tárgyaltak szerint helytelen viselkedéshez vezetne. További információ a különböző újrapróbálkozási szabályzatokról és az EF-ről: Csatlakozás ion Resiliency in EF.

Konstruktor újraírása

A fenti kód példák az alkalmazáshoz szükséges alapértelmezett konstruktor-újraírásokat szemléltetik az adatfüggő útválasztás az Entity Framework használatával való használatához. Az alábbi táblázat általánosítja ezt a megközelítést más konstruktorokra.

Jelenlegi konstruktor Az adatok konstruktorának újraírása Alapkonstruktor Jegyzetek
MyContext() ElasticScaleContext(ShardMap, TKey) DbContext(Db Csatlakozás ion, bool) A kapcsolatnak a szegmenstérkép és az adatfüggő útválasztási kulcs függvényének kell lennie. Át kell adnia az automatikus kapcsolat ef általi létrehozását, és ehelyett a szegmenstérképet kell használnia a kapcsolat közvetítéséhez.
MyContext(sztring) ElasticScaleContext(ShardMap, TKey) DbContext(Db Csatlakozás ion, bool) A kapcsolat a szegmenstérkép és az adatfüggő útválasztási kulcs függvénye. A rögzített adatbázisnév vagy kapcsolati sztring nem működik, mivel a szegmenstérkép által végzett ellenőrzésük során a rendszer nem végzi el a hitelesítést.
MyContext(DbCompiledModel) ElasticScaleContext(ShardMap, TKey, DbCompiledModel) DbContext(Db Csatlakozás ion, DbCompiledModel, bool) A kapcsolat létrejön a megadott szegmenstérképhez és szilánkkulcshoz a megadott modellel. A lefordított modell tovább lesz adva az alapkonstruktornak.
MyContext(Db Csatlakozás ion, bool) ElasticScaleContext(ShardMap, TKey, bool) DbContext(Db Csatlakozás ion, bool) A kapcsolatot a szegmenstérképből és a kulcsból kell következtetni. Bemenetként nem adható meg (kivéve, ha a bemenet már a szegmenstérképet és a kulcsot használta). A logikai érték tovább lesz adva.
MyContext(sztring, DbCompiledModel) ElasticScaleContext(ShardMap, TKey, DbCompiledModel) DbContext(Db Csatlakozás ion, DbCompiledModel, bool) A kapcsolatot a szegmenstérképből és a kulcsból kell következtetni. Bemenetként nem adható meg (kivéve, ha a bemenet a szegmenstérképet és a kulcsot használta). A lefordított modell tovább lesz adva.
MyContext(ObjectContext, bool) ElasticScaleContext(ShardMap, TKey, ObjectContext, bool) DbContext(ObjectContext, bool) Az új konstruktornak gondoskodnia kell arról, hogy az ObjectContext bemenetként átadott kapcsolatait a rendszer átirányítsa egy rugalmas méretezés által felügyelt kapcsolatra. Az ObjectContexts részletes ismertetése meghaladja a dokumentum hatókörét.
MyContext(Db Csatlakozás ion, DbCompiledModel, bool) ElasticScaleContext(ShardMap, TKey, DbCompiledModel, bool) DbContext(Db Csatlakozás ion, DbCompiledModel, bool); A kapcsolatot a szegmenstérképből és a kulcsból kell következtetni. A kapcsolat nem adható meg bemenetként (kivéve, ha a bemenet már a szegmenstérképet és a kulcsot használta). A modell és a logikai érték tovább lesz adva az alaposztály konstruktorának.

Szegmensséma üzembe helyezése EF-migrálással

Az entitás-keretrendszer által biztosított kényelem az automatikus sémakezelés. A rugalmas adatbázis-eszközöket használó alkalmazások esetében meg kell őriznie ezt a képességet, hogy automatikusan kiépíteni a sémát az újonnan létrehozott szegmensekre, amikor az adatbázisokat hozzáadják a szegmenses alkalmazáshoz. Az elsődleges használati eset a kapacitás növelése az adatszinten a horizontálisan skálázott alkalmazásoknál az EF használatával. Ha az EF sémakezelési képességeire támaszkodik, azzal csökkenti az adatbázis-adminisztrációs munkát egy EF-re épülő, horizontálisan skálázott alkalmazással.

A séma ef-migráláson keresztüli üzembe helyezése a legjobban a nem megnyitott kapcsolatokon működik. Ez ellentétben áll az adatfüggő útválasztás forgatókönyvével, amely a rugalmas adatbázis-ügyfél API által biztosított megnyitott kapcsolatra támaszkodik. Egy másik különbség a konzisztenciakövetelmény: Bár az összes adatfüggő útválasztási kapcsolat konzisztenciáját biztosítani szeretné az egyidejű szegmenstérkép-kezelés elleni védelem érdekében, ez nem jelent problémát egy új adatbázis kezdeti sématelepítésével kapcsolatban, amely még nem lett regisztrálva a szegmenstérképen, és még nem lett lefoglalva a szegmensek tárolására. Ezért az adatfüggő útválasztás helyett normál adatbázis-kapcsolatokra támaszkodhat ebben a forgatókönyvben.

Ez egy olyan megközelítéshez vezet, amelyben a séma EF-migráláson keresztüli üzembe helyezése szorosan kapcsolódik az új adatbázis szegmensként való regisztrálásához az alkalmazás szegmenstérképén. Ez a következő előfeltételekre támaszkodik:

  • Az adatbázis már létrejött.
  • Az adatbázis üres – nem tartalmaz felhasználói sémát és felhasználói adatokat.
  • Az adatbázis még nem érhető el a rugalmas adatbázis-ügyfél API-kkal az adatfüggő útválasztáshoz.

Ezen előfeltételek teljesülése esetén létrehozhat egy rendszeres, nem megnyitott Sql Csatlakozás iont, amellyel elindíthatja az EF-migrálásokat a sématelepítéshez. Az alábbi kódminta ezt a megközelítést szemlélteti.

// 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);
}

Ez a minta azt a RegisterNewShard metódust mutatja be, amely regisztrálja a szegmenst a szegmenstérképen, üzembe helyezi a sémát EF-migrálásokon keresztül, és egy szegmenskulcs-leképezést tárol a szegmensre. A dbContext alosztály (ElasticScaleContext a mintában) konstruktorára támaszkodik, amely bemenetként egy SQL-kapcsolati sztring vesz igénybe. A konstruktor kódja egyenesen előre halad, ahogy az alábbi példa is mutatja:

// 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;
}

Lehet, hogy az alaposztálytól örökölt konstruktor verzióját használta. A kódnak azonban biztosítania kell, hogy a csatlakozáskor az EF alapértelmezett inicializálója legyen használva. Ezért a rövid kitérő a statikus metódusba, mielőtt behívja az alaposztály konstruktorát a kapcsolati sztring. Vegye figyelembe, hogy a szegmensek regisztrációjának egy másik alkalmazástartományban vagy folyamatban kell futnia, hogy az EF inicializáló beállításai ne ütközhessenek.

Korlátozások

A dokumentumban ismertetett megközelítések néhány korlátozást vonnak maguk után:

  • A LocalDb-t használó EF-alkalmazásoknak először egy normál SQL Server-adatbázisba kell migrálniuk, mielőtt rugalmas adatbázis-ügyfélkódtárat használnak. Az alkalmazások horizontális felskálázása rugalmas skálázással nem lehetséges a LocalDb használatával. Vegye figyelembe, hogy a fejlesztés továbbra is használhatja a LocalDb-t.
  • Az adatbázisséma-módosításokat tartalmazó alkalmazás módosításainak át kell haladnia az EF-migrálásokon az összes szegmensen. A dokumentum mintakódja nem mutatja be ennek módját. Fontolja meg az Update-Database használatát egy Csatlakozás ionString paraméterrel az összes szegmens iterálásához; vagy a függőben lévő migrálás T-SQL-szkriptjének kinyerése az Update-Database használatával a -Script beállítással, és alkalmazza a T-SQL-szkriptet a szegmensekre.
  • A kérelem alapján feltételezzük, hogy az adatbázis-feldolgozás egyetlen szegmensben található, a kérés által biztosított skálázási kulcs alapján. Ez a feltételezés azonban nem mindig igaz. Ha például nem lehet elérhetővé tenni egy szegmenskulcsot. Ennek megoldásához az ügyfélkódtár biztosítja a MultiShardQuery osztályt, amely egy kapcsolat absztrakcióját valósítja meg több szegmensen keresztüli lekérdezéshez. Tanulás a A MultiShardQuery és az EF együttes használata meghaladja a dokumentum hatókörét

Összefoglalás

A dokumentumban ismertetett lépések révén az EF-alkalmazások az EF-alkalmazásban használt DbContext alosztályok konstruktorainak újrabontásával használhatják a rugalmas adatbázis-ügyfélkódtár adatfüggő útválasztási képességét. Ez korlátozza azoknak a helyeknek a módosításait, ahol a DbContext-osztályok már léteznek. Emellett az EF-alkalmazások továbbra is élvezhetik az automatikus sématelepítés előnyeit, ha kombinálják a szükséges EF-migrálásokat kezdeményező lépéseket az új szegmensek és leképezések regisztrálásával a szegmenstérképen.

További információforrások

Még nem használ rugalmas adatbázis-eszközöket? Tekintse meg az első lépések útmutatót. Ha kérdése van, lépjen kapcsolatba velünk az SQL Database-hez készült Microsoft Q&A kérdésoldalon, és a funkciókérésekért, adjon hozzá új ötleteket, vagy szavazzon a meglévő ötletekre az SQL Database visszajelzési fórumában.