In Entity Framework 6, we had the option to run a stored procedure that returns a specific model object with code like this:
context.Database.SqlQuery<MyModelClass>("SomeStoredProcedure #p0", param1).ToList();
where MyModelClass represents the result set from the stored procedure.
My question is do we have similar kind of option in Entity Framework Core? So far I've been able to find FromSQL but (I could be wrong) this method expects the dbset name, whereas I want to provide plain model class name (because there could be multiple stored procedures with multiple models)
Any suggestion would be greatly appreciated.
Thanks.
So I figured out that for this kind of scenario we'll have to use Keyless entity types feature provided by Entity Framework Core 3.0. Here is how it worked form me.
First of all, in the OnModelCreating event of DbContext, introduce the entity type like this
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder
.Entity<MyModelClassName>(m=>
{
m.HasNoKey();
});
}
Now we'll simply call the stored procedure like this
context.Set<MyModelClassName>().FromSqlRaw("MyStoredProcedureName").ToList();
Thanks.
Related
I am working on ASP.NET Core MVC Application that uses Entity framework Core. So everything seemed ok but somehow i came up with an interesting question and couldn't find the answer in the web.
Here what i know.
When we use EF Core it gives us ability to represent database tables as classes and to work with them. I have a CONTEXT.cs class that creates entities, gives them properties corresponding to database.
Here is my question
If a model is a class then where is the constructor? Or that is done when i "create" something and the whole info comes to controller like this( [Bind("id", "name") ]Materials materials) and data is simply being added to context
Thanks in advance. Please correct me if i'm writing anything wrong
I think that this link will answer the first part of your question:
https://learn.microsoft.com/en-us/ef/core/modeling/constructors
And about binding models which coming from controller actions. At least in previous versions, the data was set through public field setters that can implement complex logic. For example, a boolean setter can actually add a value to a private List when assigning a 'true' value.
My ASP.NET MVC web app needs to get data from existing database using T-SQL stored procedures. I've seen tutorials on how to do that using the code-first approach (basically for a model named Product, the Entity Framework generates stored procedures like Product_Update, Product_Delete, etc).
But in my case I can't use code-first b/c the database and the stored procedures already exist and their names don't follow this convention. What's the way to go? Any help will be appreciated. Thanks in advance.
Begin Edited 2017-03-28
If I go about using straight ADO.NET classes as Shyju and WillHua said, will data annotations on my Model data classes work? If not, how else can validation, etc be implemented?
If I follow this approach, do I need to reference Entity Framework in my project at all?
End Edited 2017-03-28
If you're using Entity Framework you could do something similar to the following:
var startDateParam = new SqlParameter("StartDate", 8) { Value = startDate };
var endDateParam = new SqlParameter("EndDate", 8) { Value = endDate };
var parameters = new[] { startDateParam, endDateParam };
var result= Context.Database.SqlQuery<CampaignReferralReportItem>("CampaignReferralReportItems #StartDate, #EndDate", parameters).ToList<CampaignReferralReportItem>();
return result;
So what you've got here is the declaration of two parameters which are passed into the Stored Procedure 'CampaignReferralReportItems'. After the query is complete, the result is mapped as closely as possible to the class CampaignReferralReportItem.
Keep in mind the order of the properties must be identical as the query results or the mapping can throw exceptions.
It's worth noting that the Context stated in the above code is your DataContext.
Also, before you start throwing this kind of code everywhere. It might be worthwhile looking at the Repository pattern
I'd suggest either using Dapper, which I am strating to use, and love for it's speed - or, Entity Framework, and 'Update model from Database' - so, a database first approach, where the references to the procs are pulled in.
But, I'd suggest Dapper, as it's pretty simple and quick.
I'm using Entity Framework 5, and I reverse engineer code first the database I'm using, and then I added an ADO.NET Entity Data Model so that I can use Stored Procedures as reverse engineer code first didn't provide the use of sprocs. Is this the only way to access sprocs?
Also, I realize that after the reverse engineer code first process is done a bunch of classes (tables from the database) are created but as soon as I add the ADO.NET Entity Data Model, most of the classes go away. Does anybody know why?
DbContext.Database property exposes useful methods
http://msdn.microsoft.com/en-us/library/system.data.entity.database(v=vs.103).aspx
ExecuteSqlCommand( string, object[] )
http://msdn.microsoft.com/en-us/library/system.data.entity.database.executesqlcommand(v=vs.103).aspx
SqlQuery<TEntity>( string, object[] )
http://msdn.microsoft.com/en-us/library/gg696545(v=vs.103).aspx
There is a pattern that you can follow to create or support store procedures with the code first approach. here is a link that you can use to follow this:
http://www.codeproject.com/Articles/179481/Code-First-Stored-Procedures
In few words you need to do the same that you do with model first, create a class that supports the inputs and a class that supports the result set.
And about the Data Entity Model and missing classes. You need to consider that you only can have one approach in a project: code first/(model first/database first), so this could be the reason why you are not seeing those clases.
You can use Context.Database.SqlQuery to run SP.
I'm using Self Tracking Entities that implements IObjectWithChangeTracker with the last Entity Framework RC available as a Nuget. The target database is PostgreSQL. I'm also using Code First fluent API to construct the model and LINQ to Entity for querying the database.
To my surpise, a simple SELECT query on the entity generates a SQL query with a mysterious column ChangeTracker_ChangeTrackingEnabled that does not exist in the datatable ! I do not understand this behavior as it seems to me that the EntityTypeConfiguration derived class maps the entity properties to the datatable columns in its constructor.
Is there a way to disable this behavior or at least tell which column should be mapped by the change tracker ?
For that purpose, Context.Configuration.AutoDetectChangesEnabled = false or calling IsConcurrencyToken() mapping in the EntityTypeConfiguration derived object does not help.
Any help appreciated.
TIA.
You must inform EF about every public property you want to avoid in mapping by either marking property with NotMapped attribute or by using Ignore in fluent API.
Btw. as I know STEs are not designed to be used with code first or DbContext API.
With CTP4, I used to be able to do the following (as suggested by ptrandem):
modelBuilder.IncludeMetadataInDatabase = false
With this line of code, EF doesn't create the EdmMetadata table in my database, and doesn't track model changes.
I was unable to find a way to accomplish this in the new CTP5, so now every time I change my model, I get this:
The model backing the 'MyContext'
context has changed since the database
was created. Either manually
delete/update the database, or call
Database.SetInitializer with an
IDatabaseInitializer instance. For
example, the
DropCreateDatabaseIfModelChanges
strategy will automatically delete and
recreate the database, and optionally
seed it with new data.
So, does everybody know where is the IncludeMetadataInDatabase property in CTP5? Thanks.
CTP5 includes a very cool feature called Pluggable Conventions that can be used to Add/Remove conventions. IncludeMetadataInDatabase has been removed and being replaced with a
pluggable convention that does the same thing for you:
modelBuilder.Conventions
.Remove<System.Data.Entity.Database.IncludeMetadataConvention>();
The equivalent in CTP5 to switch off initializer logic: In your Application_Start in Global.asax, enter the following:
System.Data.Entity.Database.DbDatabase.SetInitializer<MyDBContext>(null);
In EF 4.1
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Remove<IncludeMetadataConvention>();
}
Have been looking for this all over, and I had to find the answer right after posting my question, DUH. Right from the ADO.NET team blog:
In CTP5 we have removed the need to
perform additional configuration when
mapping to an existing database. If
Code First detects that it is pointing
to an existing database schema that it
did not create then it will ‘trust
you’ and attempt to use code first
with the schema. The easiest way to
point Code First to an existing
database is to add a App/Web.config
connection string with the same name
as your derived DbContext (...)