Állványzat (Fordított tervezés)

A fordított tervezés az entitástípusosztályok és egy adatbázisséma alapján egy DbContext osztály létrehozásának folyamata. Ez az Scaffold-DbContext EF Core Package Manager-konzol (PMC) eszközeinek vagy a dotnet ef dbcontext scaffold .NET parancssori felületének (CLI) parancsával végezhető el.

Note

Az itt dokumentált állványzat és az entitástípusok eltérnek az ASP.NET Core-ban a Visual Studióval használt vezérlők állványzattól, amelyet itt nem dokumentálunk.

Tip

A Visual Studio használata esetén próbálja ki az EF Core Power Tools közösségi bővítményét. Ezek az eszközök egy grafikus eszközt biztosítanak, amely az EF Core parancssori eszközeire épül, és további munkafolyamat- és testreszabási lehetőségeket kínál.

Prerequisites

  • Az előkészítési lépések előtt telepítenie kell a PMC-eszközöket, amelyek csak a Visual Studio-val működnek, vagy a .NET CLI-eszközöket, amelyek kompatibilisek a .NET által támogatott összes platformmal.
  • Telepítse a NuGet-csomagot Microsoft.EntityFrameworkCore.Design abban a projektben, amelybe az állványzat készül.
  • Telepítse annak az adatbázis-szolgáltatónak a NuGet-csomagját, amely a létrehozni kívánt adatbázissémát célozza.

Kötelező argumentumok

Mind a PMC, mind a .NET CLI parancsnak két kötelező argumentuma van: az adatbázis kapcsolati sztringje és a használni kívánt EF Core-adatbázis-szolgáltató.

Csatlakozási karakterlánc

Warning

Ez a cikk egy helyi adatbázist használ, amely nem igényli a felhasználó hitelesítését. A termelésben használt alkalmazásoknak az elérhető legbiztonságosabb hitelesítési folyamatot kell használniuk. Az üzembe helyezett teszt- és éles alkalmazások hitelesítéséről további információt Biztonságos hitelesítési folyamatokcímű témakörben talál.

A parancs első argumentuma az adatbázis kapcsolati sztringje. Az eszközök ezt a kapcsolati sztringet használják az adatbázisséma olvasásához.

A kapcsolati sztring idézetelésének és escape-elésének módját a parancs futtatásához használt shell határozza meg. Tekintse meg a shell dokumentációját. Például a PowerShellhez escape-elni kell a $, de nem a \.

Az alábbi példa az entitástípusokat és a DbContext a gép SQL Server LocalDB-példányán elérhető Chinook adatbázisból készíti elő, az Microsoft.EntityFrameworkCore.SqlServer adatbázis-szolgáltatót használva.

dotnet ef dbcontext scaffold "Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=Chinook" Microsoft.EntityFrameworkCore.SqlServer

Tip

A konfigurációval tárolhatja és lekérheti a kapcsolati sztringet

Kapcsolati sztringek az állványozott kódban

Alapértelmezés szerint a kódgenerátor tartalmazza a kapcsolati sztringet a generált kódban, de figyelmeztetéssel. Például:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
#warning To protect potentially sensitive information in your connection string, you should move it out of source code. You can avoid scaffolding the connection string by using the Name= syntax to read it from configuration - see https://go.microsoft.com/fwlink/?linkid=2131148. For more guidance on storing connection strings, see http://go.microsoft.com/fwlink/?LinkId=723263.
    => optionsBuilder.UseSqlServer("Data Source=(LocalDb)\\MSSQLLocalDB;Database=AllTogetherNow");

Ez úgy történik, hogy a létrehozott kód ne összeomlik az első használatkor, ami nagyon gyenge tanulási élmény lenne. A figyelmeztetés szerint azonban a kapcsolati sztringek nem létezhetnek az éles kódban. Tekintse meg a DbContext élettartamát, konfigurációját és inicializálását a kapcsolati sztringek kezelésének különféle módjait.

Tip

A -NoOnConfiguring (Visual Studio PMC) vagy --no-onconfiguring a (.NET CLI) lehetőség átadható a OnConfiguring kapcsolati sztringet tartalmazó metódus létrehozásának letiltásához.

Szolgáltató neve

A második argumentum a szolgáltató neve. A szolgáltató neve általában megegyezik a szolgáltató NuGet-csomagjának nevével. Például az SQL Serverhez vagy az Azure SQL-hez használja Microsoft.EntityFrameworkCore.SqlServer.

Parancssori beállítások

Az állványozási folyamat különböző parancssori beállítással vezérelhető.

Táblák és nézetek megadása

Alapértelmezés szerint az adatbázisséma összes táblája és nézete entitástípusokra van osztva. Sémák és táblák megadásával korlátozhatja, hogy mely táblák és nézetek vannak generálva.

A -Schemas (Visual Studio PMC) vagy --schema a (.NET CLI) argumentum azon táblák és nézetek sémáit határozza meg, amelyekhez az entitástípusok létre lesznek hozva. Ha ez az argumentum nincs megadva, a rendszer minden sémát tartalmaz. Ha ezt a lehetőséget választja, akkor a séma összes táblája és nézetek szerepelni fognak a modellben, még akkor is, ha nem kerülnek explicit módon belefoglalásra -Tables vagy --table használatával.

A -Tables (Visual Studio PMC) vagy --table a (.NET CLI) argumentum megadta azokat a táblákat és nézeteket, amelyekhez az entitástípusok létre lesznek hozva. Egy adott séma táblázatai vagy nézetei a "schema.table" vagy a "schema.view" formátum használatával vehetők fel. Ha ez a beállítás nincs megadva, akkor az összes tábla és nézet szerepel benne. |

Például, hogy csak a Artists és Albums táblákhoz készítsen állványzatot:

dotnet ef dbcontext scaffold ... --table Artist --table Album

A Customer és Contractor sémák összes táblájának és nézetének előkészítése:

dotnet ef dbcontext scaffold ... --schema Customer --schema Contractor

Ha például a Purchases sémából származó táblát, valamint a Customer séma Accounts és Contracts tábláit szeretné létrehozni:

dotnet ef dbcontext scaffold ... --table Customer.Purchases --table Contractor.Accounts --table Contractor.Contracts

Adatbázisnevek megőrzése

A táblázat- és oszlopnevek javítva vannak, hogy alapértelmezés szerint jobban megfeleljenek a .NET-elnevezési konvencióknak a típusok és tulajdonságok esetében. -UseDatabaseNames A (Visual Studio PMC) vagy --use-database-names a (.NET CLI) megadása letiltja ezt a viselkedést, és a lehető legnagyobb mértékben megőrzi az eredeti adatbázisneveket. Az érvénytelen .NET-azonosítók továbbra is ki lesznek javítva, és a szintetizált nevek, például a navigációs tulajdonságok továbbra is megfelelnek a .NET elnevezési konvencióknak.

Vegyük például a következő táblázatokat:

CREATE TABLE [BLOGS] (
    [ID] int NOT NULL IDENTITY,
    [Blog_Name] nvarchar(max) NOT NULL,
    CONSTRAINT [PK_Blogs] PRIMARY KEY ([ID]));

CREATE TABLE [posts] (
    [id] int NOT NULL IDENTITY,
    [postTitle] nvarchar(max) NOT NULL,
    [post content] nvarchar(max) NOT NULL,
    [1 PublishedON] datetime2 NOT NULL,
    [2 DeletedON] datetime2 NULL,
    [BlogID] int NOT NULL,
    CONSTRAINT [PK_Posts] PRIMARY KEY ([id]),
    CONSTRAINT [FK_Posts_Blogs_BlogId] FOREIGN KEY ([BlogID]) REFERENCES [Blogs] ([ID]) ON DELETE CASCADE);

Alapértelmezés szerint az alábbi táblákból a következő entitástípusok kerülnek generálásra:

public partial class Blog
{
    public int Id { get; set; }
    public string BlogName { get; set; } = null!;
    public virtual ICollection<Post> Posts { get; set; } = new List<Post>();
}

public partial class Post
{
    public int Id { get; set; }
    public string PostTitle { get; set; } = null!;
    public string PostContent { get; set; } = null!;
    public DateTime _1PublishedOn { get; set; }
    public DateTime? _2DeletedOn { get; set; }
    public int BlogId { get; set; }
    public virtual Blog Blog { get; set; } = null!;
    public virtual ICollection<Tag> Tags { get; set; } = new List<Tag>();
}

Azonban, ha a következő entitástípusokat a -UseDatabaseNames vagy --use-database-names használatával hozzuk létre, az eredmény:

public partial class BLOG
{
    public int ID { get; set; }
    public string Blog_Name { get; set; } = null!;
    public virtual ICollection<post> posts { get; set; } = new List<post>();
}

public partial class post
{
    public int id { get; set; }
    public string postTitle { get; set; } = null!;
    public string post_content { get; set; } = null!;
    public DateTime _1_PublishedON { get; set; }
    public DateTime? _2_DeletedON { get; set; }
    public int BlogID { get; set; }
    public virtual BLOG Blog { get; set; } = null!;
}

Leképezési attribútumok (más néven adatjegyzetek) használata

Az entitástípusok alapértelmezés szerint az ModelBuilder API OnModelCreating használatával vannak konfigurálva. Adja meg a -DataAnnotations (PMC) vagy --data-annotations (.NET CLI) értéket, hogy szükség esetén leképezési attribútumokat használjon.

A Fluent API használata például a következőt fogja kiépíteni:

entity.Property(e => e.Title)
    .IsRequired()
    .HasMaxLength(160);

Az adatjegyzetek használata során a következőt fogja használni:

[Required]
[StringLength(160)]
public string Title { get; set; }

Tip

A modell bizonyos aspektusai nem konfigurálhatók leképezési attribútumokkal. Az állványozó továbbra is a modellkészítő API-t használja ezeknek az eseteknek a kezelésére.

DbContext neve

Az állványzatos DbContext osztály neve alapértelmezés szerint a Context (Környezet ) utótaggal ellátott adatbázis neve lesz. Ha másikat szeretne megadni, használja -Context a PMC-ben és --context a .NET CLI-ben.

Célkönyvtárak és névterek

Az entitásosztályok és a DbContext osztály a projekt gyökérkönyvtárába van generálva, és a projekt alapértelmezett névterét használják.

Megadhatja azt a könyvtárat, ahol az osztályok --output-dir segítségével kerülnek generálásra, és a --context-dir használatával a DbContext osztályt egy külön könyvtárba generálhatja az entitás típustól eltérően:

dotnet ef dbcontext scaffold ... --context-dir Data --output-dir Models

Alapértelmezés szerint a névtér a gyökérnévtérből és a projekt gyökérkönyvtárában lévő alkönyvtárak neveiből áll össze. Az összes kimeneti osztály névterét azonban felülbírálhatja a használatával --namespace. A dbContext osztály névterét a következővel --context-namespaceis felülbírálhatja:

dotnet ef dbcontext scaffold ... --namespace Your.Namespace --context-namespace Your.DbContext.Namespace

Az állványozott kód

Egy meglévő adatbázisból történő állványozás eredménye a következő:

  • Egy fájl, amely tartalmaz egy osztályt, amely öröklődik a DbContext-ből.
  • Minden entitástípushoz tartozó fájl

Tip

Az EF7-től kezdve T4-es szövegsablonokkal testre szabhatja a létrehozott kódot. További részletekért tekintse meg az egyéni fordított tervezési sablonokat .

C# Nullable referenciatípusok

Az állványzat létrehozhat olyan EF-modellt és entitástípusokat, amelyek C# null értékű referenciatípusokat (NRT-eket) használnak. Az NRT-használat automatikusan beépül, ha az NRT-támogatás engedélyezve van abban a C#-projektben, amelybe a kód be van illesztve.

A következő Tags táblázat például mindkét null értékű, nem null értékű karakterláncoszlopot tartalmazza:

CREATE TABLE [Tags] (
  [Id] int NOT NULL IDENTITY,
  [Name] nvarchar(max) NOT NULL,
  [Description] nvarchar(max) NULL,
  CONSTRAINT [PK_Tags] PRIMARY KEY ([Id]));

Ez a létrehozott osztály megfelelő null értékű és nem null értékű sztringtulajdonságokat eredményez:

public partial class Tag
{
    public Tag()
    {
        Posts = new HashSet<Post>();
    }

    public int Id { get; set; }
    public string Name { get; set; } = null!;
    public string? Description { get; set; }

    public virtual ICollection<Post> Posts { get; set; }
}

Hasonlóképpen, a következő Posts táblák is tartalmaznak egy szükséges kapcsolatot a Blogs táblával:

CREATE TABLE [Posts] (
    [Id] int NOT NULL IDENTITY,
    [Title] nvarchar(max) NOT NULL,
    [Contents] nvarchar(max) NOT NULL,
    [PostedOn] datetime2 NOT NULL,
    [UpdatedOn] datetime2 NULL,
    [BlogId] int NOT NULL,
    CONSTRAINT [PK_Posts] PRIMARY KEY ([Id]),
    CONSTRAINT [FK_Posts_Blogs_BlogId] FOREIGN KEY ([BlogId]) REFERENCES [Blogs] ([Id]));

Ez a blogok közötti nem null értékű (kötelező) kapcsolat szerkezetét eredményezi:

public partial class Blog
{
    public Blog()
    {
        Posts = new HashSet<Post>();
    }

    public int Id { get; set; }
    public string Name { get; set; } = null!;

    public virtual ICollection<Post> Posts { get; set; }
}

És bejegyzések:

public partial class Post
{
    public Post()
    {
        Tags = new HashSet<Tag>();
    }

    public int Id { get; set; }
    public string Title { get; set; } = null!;
    public string Contents { get; set; } = null!;
    public DateTime PostedOn { get; set; }
    public DateTime? UpdatedOn { get; set; }
    public int BlogId { get; set; }

    public virtual Blog Blog { get; set; } = null!;

    public virtual ICollection<Tag> Tags { get; set; }
}

Többszörös kapcsolatok

Az állványzati folyamat észleli az egyszerű illesztési táblákat, és automatikusan létrehoz egy több-a-többhöz leképezést . Például vegye figyelembe a Posts és Tags táblázatokat, valamint az őket összekapcsoló PostTag kapcsolótáblát.

CREATE TABLE [Tags] (
  [Id] int NOT NULL IDENTITY,
  [Name] nvarchar(max) NOT NULL,
  [Description] nvarchar(max) NULL,
  CONSTRAINT [PK_Tags] PRIMARY KEY ([Id]));

CREATE TABLE [Posts] (
    [Id] int NOT NULL IDENTITY,
    [Title] nvarchar(max) NOT NULL,
    [Contents] nvarchar(max) NOT NULL,
    [PostedOn] datetime2 NOT NULL,
    [UpdatedOn] datetime2 NULL,
    CONSTRAINT [PK_Posts] PRIMARY KEY ([Id]));

CREATE TABLE [PostTag] (
    [PostsId] int NOT NULL,
    [TagsId] int NOT NULL,
    CONSTRAINT [PK_PostTag] PRIMARY KEY ([PostsId], [TagsId]),
    CONSTRAINT [FK_PostTag_Posts_TagsId] FOREIGN KEY ([TagsId]) REFERENCES [Tags] ([Id]) ON DELETE CASCADE,
    CONSTRAINT [FK_PostTag_Tags_PostsId] FOREIGN KEY ([PostsId]) REFERENCES [Posts] ([Id]) ON DELETE CASCADE);

Ha állványzatot hoz létre, ez a Post osztályt eredményezi:

public partial class Post
{
    public Post()
    {
        Tags = new HashSet<Tag>();
    }

    public int Id { get; set; }
    public string Title { get; set; } = null!;
    public string Contents { get; set; } = null!;
    public DateTime PostedOn { get; set; }
    public DateTime? UpdatedOn { get; set; }
    public int BlogId { get; set; }

    public virtual Blog Blog { get; set; } = null!;

    public virtual ICollection<Tag> Tags { get; set; }
}

És egy osztály a Címkéhez:

public partial class Tag
{
    public Tag()
    {
        Posts = new HashSet<Post>();
    }

    public int Id { get; set; }
    public string Name { get; set; } = null!;
    public string? Description { get; set; }

    public virtual ICollection<Post> Posts { get; set; }
}

De nincs osztály a PostTag táblához. Ehelyett a több-a-többhöz kapcsolat konfigurációja a következő:

entity.HasMany(d => d.Tags)
    .WithMany(p => p.Posts)
    .UsingEntity<Dictionary<string, object>>(
        "PostTag",
        l => l.HasOne<Tag>().WithMany().HasForeignKey("PostsId"),
        r => r.HasOne<Post>().WithMany().HasForeignKey("TagsId"),
        j =>
            {
                j.HasKey("PostsId", "TagsId");
                j.ToTable("PostTag");
                j.HasIndex(new[] { "TagsId" }, "IX_PostTag_TagsId");
            });

Egyéb programozási nyelvek

A Microsoft által közzétett EF Core-csomagok automatikusan generálnak C# kódot. A mögöttes állványzatrendszer azonban támogatja a beépülő modulmodellt más nyelvekre való állványozáshoz. Ezt a beépülő modulmodellt különböző közösségi projektek használják, például:

A kód testreszabása

Az EF7-től kezdve a generált kód testreszabásának egyik legjobb módja a létrehozáshoz használt T4-sablonok testreszabása.

A kód a létrehozás után is módosítható, de ennek legjobb módja attól függ, hogy újra szeretné-e futtatni az állványozási folyamatot az adatbázismodell változásakor.

Állványzat csak egyszer

Ezzel a megközelítéssel az állványozott kód kiindulópontként szolgál a kódalapú leképezések előrehaladtához. A létrehozott kód bármilyen módosítása igény szerint végezhető el – a projekt bármely más kódjához hasonlóan normál kód lesz.

Az adatbázis és az EF-modell szinkronizálása kétféleképpen végezhető el:

  • Váltson a EF Core-adatbázis-migrációk használatára, és az entitástípusokat, valamint az EF-modell konfigurációját tekintse egyetlen hiteles forrásként, és alkalmazza a migrációkat a séma kezelésére.
  • Az adatbázis módosításakor manuálisan frissítse az entitástípusokat és az EF-konfigurációt. Ha például új oszlopot ad hozzá egy táblához, akkor adjon hozzá egy tulajdonságot az oszlophoz a megfeleltetett entitástípushoz, és adja hozzá a szükséges konfigurációt leképezési attribútumok és/vagy kód OnModelCreatinghasználatával. Ez viszonylag egyszerű, és az egyetlen valódi kihívást az jelenti, hogy az adatbázis módosításait valamilyen módon rögzítsük vagy észleljük, hogy a kódért felelős fejlesztő(k) reagálni tudjanak.

Ismétlődő állványzat

Az egyszer végzett állványozás másik módszere, hogy minden alkalommal újraszerkeszti az adatbázist, amikor az adatbázis megváltozik. Ez felülírja a korábban létrehozott kódokat, ami azt jelenti, hogy az entitástípusokon vagy az EF-konfiguráción végzett módosítások elvesznek a kódban.

[TIPP] Alapértelmezés szerint az EF-parancsok nem írnak felül meglévő kódot a véletlen kódvesztés elleni védelem érdekében. A -Force (Visual Studio PMC) vagy --force a (.NET CLI) argumentummal kényszerítheti a meglévő fájlok felülírását.

Mivel az állványozott kód felülíródik, a legjobb, ha nem közvetlenül módosítja, hanem részleges osztályokra és metódusokra támaszkodik, valamint az EF Core azon mechanizmusaira, amelyek lehetővé teszik a konfiguráció felülbírálását. Specifically:

  • Az DbContext osztály és az entitásosztályok is részlegesen jönnek létre. Ez lehetővé teszi, hogy további tagokat és kódot vezessen be egy külön fájlba, amely nem lesz felülírva az állványzat futtatásakor.
  • Az DbContext osztály tartalmaz egy részleges metódust.OnModelCreatingPartial Ennek a metódusnak a implementációja hozzáadható a részleges osztályhoz a DbContext. Ezt követően meghívásra kerül, miután OnModelCreating meghívásra kerül.
  • Az API-k használatával létrehozott modellkonfiguráció felülbírálja a ModelBuilder konvenciók vagy leképezési attribútumok által végzett konfigurációkat, valamint a modellkészítőn végzett korábbi konfigurációkat. Ez azt jelenti, hogy a beírt OnModelCreatingPartial kód az állványozási folyamat által létrehozott konfiguráció felülbírálására használható anélkül, hogy el kellene távolítania a konfigurációt.

Végül ne feledje, hogy az EF7-től kezdve a kód létrehozásához használt T4-sablonok testre szabhatók. Ez gyakran hatékonyabb megközelítés, mint alapértelmezésekre építés, majd módosítás részleges osztályokkal és/vagy metódusokkal.

Hogyan működik?

A visszafejtés az adatbázisséma olvasásával kezdődik. Beolvassa a táblákra, oszlopokra, korlátozásokra és indexekre vonatkozó információkat.

A következő lépésben a sémainformációkat használja egy EF Core-modell létrehozásához. A táblák entitástípusok létrehozására szolgálnak; az oszlopok tulajdonságok létrehozására szolgálnak; és idegen kulcsok használatával hozhatók létre kapcsolatok.

Végül a rendszer a modellt használja a kód létrehozásához. A megfelelő entitástípusosztályok, a Fluent API és az adatjegyzetek úgy vannak összeállítva, hogy ugyanazt a modellt újra létrehozhassa az alkalmazásból.

Limitations

  • Nem minden modell ábrázolható adatbázisséma használatával. Az öröklési hierarchiákról, a tulajdonban lévő típusokról és a táblák felosztásáról szóló információk például nem szerepelnek az adatbázissémában. Emiatt ezek a szerkezetek soha nem lesznek állványzatok.
  • Emellett előfordulhat, hogy az EF Core-szolgáltató nem támogatja bizonyos oszloptípusokat . Ezek az oszlopok nem lesznek belefoglalva a modellbe.
  • Egyidejűségi jogkivonatokat definiálhat egy EF Core-modellben, hogy két felhasználó egyszerre ne frissítse ugyanazt az entitást. Egyes adatbázisok speciális típussal rendelkeznek az ilyen típusú oszlopok képviseletére (például a rowversion az SQL Serverben), amely esetben ezeket az információkat visszafejthetjük; más egyidejűségi azonosítók azonban nem lesznek kiszolgálva.
  • Last updated on