Supposedly, I have a simple DbContext with Blog and Post models:
public class Blog
{
public int BlogId { get; set; }
public string Name { get; set; }
public ICollection<Post> Posts { get; set; }
}
public class Post
{
public int PostId { get; set; }
public string Title { get; set; }
public string Content { get; set; }
public int BlogId { get; set; }
public Blog Blog { get; set; }
}
Let's say I have a stored procedure that returns some DTO:
[Keyless]
public class BlogPostDto
{
public string PostTitle { get; init; }
public string BlogName { get; init; }
}
Today I put the following into DbContext:
public class AppDbContext : DbContext {
public virtual DbSet<BlogPostDto> NeverUseIt { get; set; }
partial void OnModelCreatingPartial(ModelBuilder modelBuilder) {
modelBuilder.Entity<BlogPostDto>().ToView(null);
}
}
And then I can get Stored Procedure results shaped in the way I want:
List<BlogPostDto> results = await db.Set<BlogPostDto>().FromSqlRaw($"EXEC MyProc").ToListAsync();
So, my question is, do I have to add my BlogPostDto into DbContext? I know that in EF Core 3 I did; but there were a large number of improvements since then. Creating a bogus DbSet and mapping it to non-existent view just feels counter-intuitive!
The closest I found in most current documentation is here. The very first example of context is Serving as the return type for raw SQL queries. - but the article assumes that I have a matching view already in the database.
UPDATE: It looks like ToView(null) is not necessary - just DbSet<>