Czy Entity Framework Code First obsługuje procedury składowane?

Obejrzałem kilka prezentacji EF Code First i nie widziałem, jak EFCF działa z procedurami składowanymi.

Jak mogę zadeklarować metodę, która będzie korzystała z niektórych sp? Czy mogę przekazać jednostkę do metody, która wywołuje sp bez ręcznego mapowania właściwości jednostki na parametry sp?

Co się stanie, jeśli zmienię model? Czy spowoduje to spadek mojego sp podczas odtwarzania tabeli z modelu? A co z wyzwalaczami?

Jeśli te rzeczy nie są obsługiwane, czy są jakieś plany, aby wspierać je w przyszłości?

EDYCJA: Moja pierwotna odpowiedź dotycząca EF4.1 (poniżej) jest teraz nieaktualna. Zobacz odpowiedź poniżej od Diego Vegi (który pracuje w zespole EF w firmie Microsoft)!

@gsharp i Shawn Mclean: Skąd bierzesz te informacje? Czy nadal nie masz dostępu do bazowego ObjectContext?

IEnumerable<Customer> customers = 
    ((IObjectContextAdapter)this)
    .ObjectContext.ExecuteStoreQuery<Customer>("select * from customers");

Zastąp instrukcję „select” zapisanym procesem i gotowe.

A jeśli chodzi o twoje drugie pytanie: tak, niestety twoje sp's zostaną zablokowane. Może być konieczne dodanie instrukcji „CREATE PROCEDURE” do kodu.

Dla EF 4.2:

var customers = context.Database.SqlQuery<Customer>("select * from customers")

Aktualizacja: od EF6 EF Code First obsługuje mapowanie procedur składowanych dla wstawiania, aktualizacji i usuwania. Mapowanie procedury składowanej można określić podczas tworzenia modelu przy użyciu metody MapToStoredProcedures. Obsługujemy również automatyczne tworzenie szkieletów podstawowych procedur składowanych dla tych operacji. Zobacz specyfikację funkcji tutaj .

Oryginalna odpowiedź: nie będziemy obsługiwać mapowania procedur składowanych w modelu w Code-First w pierwszej wersji ani nie będziemy mieć możliwości automatycznego generowania procedur składowanych dla operacji CRUD z Twoich typów. Są to funkcje, które chcielibyśmy dodać w przyszłości.

Jak wspomniano w tym wątku, można wrócić do ObjectContext, ale DbContext zapewnia również ładne interfejsy API do wykonywania natywnych zapytań i poleceń SQL (np. DbSet.SqlQuery, DbContext.Database.SqlQuery i DbContext.Database.ExecuteSqlCommand). Różne wersje SqlQuery mają te same podstawowe funkcje materializacji, które istnieją w EF4 (np. ExecuteStoreQuery: http://msdn.microsoft.com/en-us/library/dd487208.aspx ).

Mam nadzieję że to pomoże.

    public IList<Product> GetProductsByCategoryId(int categoryId)
    {
        IList<Product> products;

        using (var context = new NorthwindData())
        {
            SqlParameter categoryParam = new SqlParameter("@categoryID", categoryId);
            products = context.Database.SqlQuery<Product>("Products_GetByCategoryID @categoryID", categoryParam).ToList();
        }

        return products;
    }

    public Product GetProductById(int productId)
    {
        Product product = null;

        using (var context = new NorthwindData())
        {
            SqlParameter idParameter = new SqlParameter("@productId", productId);
            product = context.Database.SqlQuery<Product>("Product_GetByID @productId", idParameter).FirstOrDefault();
        }

        return product;
    }

Bardziej bezpieczne rozwiązanie byłoby następujące:

http://strugglesofacoder.blogspot.be/2012/03/calling-stored-procedure-with-entity.html

Zastosowanie tej klasy to:

var testProcedureStoredProcedure = new TestProcedureStoredProcedure() { Iets = 5, NogIets = true };

var result = DbContext.Database.ExecuteStoredProcedure(testProcedureStoredProcedure);

W przypadku platformy .NET Core (EntityFrameworkCore) udało mi się je uruchomić.

Może nie jest to najładniejsze, ale to zdecydowanie działa.

Migracja w celu dodania procedury składowanej wygląda następująco :

using Microsoft.EntityFrameworkCore.Migrations;
using System.Text;

namespace EFGetStarted.AspNetCore.NewDb.Migrations
{
    public partial class StoredProcedureTest : Migration
    {
        protected override void Up(MigrationBuilder migrationBuilder)
        {
            StringBuilder sb = new StringBuilder();
            sb.AppendLine("CREATE PROCEDURE GetBlogForAuthorName");
            sb.AppendLine("@authorSearch varchar(100)");
            sb.AppendLine("AS");
            sb.AppendLine("BEGIN");
            sb.AppendLine("-- SET NOCOUNT ON added to prevent extra result sets from interfering with SELECT statements.");
            sb.AppendLine("SET NOCOUNT ON;");
            sb.AppendLine("SELECT  Distinct Blogs.BlogId, Blogs.Url");
            sb.AppendLine("FROM Blogs INNER JOIN");
            sb.AppendLine("Posts ON Blogs.BlogId = Posts.BlogId INNER JOIN");
            sb.AppendLine("PostsAuthors ON Posts.PostId = PostsAuthors.PostId Inner JOIN");
            sb.AppendLine("Authors on PostsAuthors.AuthorId = Authors.AuthorId");
            sb.AppendLine("Where Authors.[Name] like '%' + @authorSearch + '%'");
            sb.AppendLine("END");

            migrationBuilder.Sql(sb.ToString());
        }

        protected override void Down(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.Sql("DROP PROCEDURE GetBlogForAuthorName");
        }
    }
}

Mógłbym wtedy zadzwonić za pomocą następującego kodu:

var blogs = _context.Blogs.FromSql("exec GetBlogForAuthorName @p0", "rod").Distinct();

Później próbowano pobrać niektóre powiązane dane (dane dotyczące relacji jeden do wielu, np. Treść posta) i blog wrócił z wypełnioną treścią posta zgodnie z oczekiwaniami.