Peut-on créer des vues sql / des procédures stockées en utilisant Entity Framework 4.1 Code first approach ?

Question

Entity Framework 4.1 Code First fonctionne très bien pour créer des tables et des relations. Est-il possible de créer des vues sql ou des procédures stockées en utilisant l'approche Code first ? Toute indication à ce sujet sera très appréciée. Merci beaucoup !

Answer 1

Nous supportons les procédures stockées dans nos migrations Entity Framework Code First. Notre approche consiste à créer un dossier pour contenir les fichiers .sql (~/Sql/ par exemple). Créez des fichiers .sql dans le dossier pour la création et la suppression de la procédure stockée. Par exemple Create_sp_DoSomething.sql y Drop_sp_DoSomething . Parce que le SQL s'exécute dans un lot et CREATE PROCEDURE.. doit être la première déclaration d'un lot, faire le CREATE PROCEDURE... la première déclaration du fichier. De même, ne mettez pas GO après le DROP... . Ajoutez un fichier de ressources à votre projet, si vous n'en avez pas déjà un. Faites glisser les fichiers .sql de l'explorateur de solutions vers la vue Fichiers du concepteur de ressources. Créez maintenant une migration vide ( Add-Migration SomethingMeaningful_sp_DoSomething ) et utiliser :

namespace MyApplication.Migrations
{
    using System;
    using System.Data.Entity.Migrations;

    public partial class SomethingMeaningful_sp_DoSomething : DbMigration
    {
        public override void Up()
        {
            this.Sql(Properties.Resources.Create_sp_DoSomething);
        }

        public override void Down()
        {
            this.Sql(Properties.Resources.Drop_sp_DoSomething);
        }
    }
}

~/Sql/Create_sp_DoSomething.sql

CREATE PROCEDURE [dbo].[sp_DoSomething] AS
BEGIN TRANSACTION
-- Your stored procedure here
COMMIT TRANSACTION
GO

~/Sql/Drop_sp_DoSomething.sql

DROP PROCEDURE [dbo].[sp_DoSomething]

Answer 2

À première vue, j'aime beaucoup l'approche de Carl G, mais elle implique beaucoup d'interaction manuelle. Dans mon scénario, je laisse toujours tomber toutes les procédures stockées, les vues... et je les recrée chaque fois qu'il y a un changement dans la base de données. De cette façon, nous sommes sûrs que tout est à jour avec la dernière version.

La récréation se fait en paramétrant l'initialisateur suivant :

Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyContext, Configuration>());

Ensuite, notre méthode d'ensemencement sera appelée chaque fois qu'une migration sera prête.

protected override void Seed(DeploymentLoggingContext context)
    {
        // Delete all stored procs, views
        foreach (var file in Directory.GetFiles(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Sql\\Seed"), "*.sql"))
        {
            context.Database.ExecuteSqlCommand(File.ReadAllText(file), new object[0]);
        }

        // Add Stored Procedures
        foreach (var file in Directory.GetFiles(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Sql\\StoredProcs"), "*.sql"))
        {
            context.Database.ExecuteSqlCommand(File.ReadAllText(file), new object[0]);
        }
    }

Les déclarations SQL sont stockées dans des fichiers *.sql pour une édition facile. Assurez-vous que vos fichiers ont l'option "Build Action" réglée sur "Content" et l'option "Copy to Output Directory" réglée sur "Copy Always". Nous recherchons les dossiers et exécutons tous les scripts à l'intérieur. N'oubliez pas d'exclure les instructions "GO" de votre SQL car elles ne peuvent pas être exécutées avec ExecuteSqlCommand().

La disposition actuelle de mon répertoire est la suivante :

Projet.DAL
+ Migrations
+ Sql
++ Graine
+++ dbo.cleanDb.sql
++ StoredProcs
+++ dbo.sp_GetSomething.sql

Maintenant, il suffit de déposer des procédures stockées supplémentaires dans le dossier et tout sera mis à jour de manière appropriée.

Answer 3

Pour développer La réponse de bbodenmiller Dans Entity Framework 6, le Classe DbMigration possède des méthodes telles que AlterStoredProcedure qui permettent de modifier les procédures stockées sans avoir à descendre jusqu'au langage SQL brut.

Voici un exemple de Up() qui modifie une procédure stockée existante du serveur SQL nommée EditItem qui prend trois paramètres de type int , nvarchar(50) y smallmoney respectivement :

public partial class MyCustomMigration : DbMigration
{
    public override void Up()
    {
        this.AlterStoredProcedure("dbo.EditItem", c => new
        {
            ItemID = c.Int(),
            ItemName = c.String(maxLength:50),
            ItemCost = c.Decimal(precision: 10, scale: 4, storeType: "smallmoney")
        }, @" (Stored procedure body SQL goes here) "   
    }

    //...
}

Sur ma machine, cette migration script produit le SQL suivant :

ALTER PROCEDURE [dbo].[EditItem]
    @ItemID [int],
    @ItemName [nvarchar](50),
    @ItemCost [smallmoney]
AS
BEGIN
    (Stored procedure body SQL goes here)
END

Answer 4

L'approche EF code-first suppose qu'il n'y a pas de logique dans la base de données. Cela signifie qu'il n'y a pas de procédures stockées ni de vues de la base de données. Pour cette raison, l'approche code-first ne fournit aucun mécanisme permettant de générer automatiquement de telles constructions pour vous. Comment pourrait-elle le faire si cela signifie générer de la logique ?

Vous devez les créer vous-mêmes dans initialisateur de base de données personnalisé en exécutant manuellement les scripts de création scripts. Je ne pense pas que ces constructions SQL personnalisées puissent être gérées par les migrations SQL.

Answer 5

Il semble qu'il soit mal documenté, mais il semble que vous puissiez maintenant faire quelques manipulations de procédures stockées en utilisant AlterStoredProcedure , CreateStoredProcedure , Procédure DropStoredProcedure , Procédure de déplacement des stocks , RenameStoredProcedure dans Entity Framework 6. Je ne les ai pas encore essayés et je ne peux donc pas encore donner un exemple de leur utilisation.