I am looking for a way to map stored procedures logically related to a table as functions within the Entity generated for that specific table instead of function in overall Context.
As an example, I have generated edmx out of existing bank database and I got a Context and several entities corresponding to the tables. Assume we have tables for Account, Transactions, Address, etc... and I have a stored proc returning current balance for the account. I want to map this stored proc to the Account entity instead of the context. This will help me to call Account.GetBalance() instead of Context.GetBalance().
Is this possible in entity framework ? I did lot of search and read few articles/blogs in msdn but couldn't find any solution for this.
No it is not possible unless you manually wrap the method exposed on context in your entity - that would make your entities persistence aware and EF dependent which is currently considered as exact opposite of design people should follow.
In terms of EF balance should be property of account entity and retrieving balance should mean reloading account or executing projection query (or your procedure) on accounts set / context. Queries are executed from context and stored procedures as well.
Related
I just found some really strange behaviour which turns out it is not so strange at all.
My select statement (query from database) worked only the first time. The second time, query from database was cached.
Inside Hub method I read something from database every 10 seconds and return result to all connected clients. But if some API change this data, Hub context does not read actual data.
In this thread I found this:
When you use EF it by default loads each entity only once per context. The first query creates entity instance and stores it internally. Any subsequent query which requires entity with the same key returns this stored instance. If values in the data store changed you still receive the entity with values from the initial query. This is called Identity map pattern. You can force the object context to reload the entity but it will reload a single shared instance.
So my question is how to properly use EFCore inside SignalR Core hub method?
I could use AsNoTracking, but I would like to use some global setting. Developer can easily forget to add AsNoTracking and this could mean serving outdated data to user.
I would like to write some code in my BaseHub class which will tell context do not track data. If I change entity properties, SaveChanges should update data. Can this be achieved? It is hard to think all the time to add AsNoTracking when querying from hub method.
I would like to write some code in my BaseHub class which will tell context do not track data.
The default query tracking behavior is controlled by the ChangeTracker.QueryTrackingBehavior property with default value of TrackAll (i.e. tracking).
You can change it to NoTracking and then use AsTracking() for queries that need tracking. It's a matter of which are more commonly needed.
If I change entity properties, SaveChanges should update data.
This is not possible if the entity is not tracked.
If you actually want tracking queries with "database wins" strategy, I'm afraid it's not possible currently in EF Core. I think EF6 object context services had an option for specifying the "client wins" vs "database wins" strategy, but EF Core currently does not provide such control and always implements "client wins" strategy.
I've got an application with MVC and Entity Framework. The application uses Unit of Work and Repository patterns for CRUD operations. But I've got to add now a couple of stored procedures that already exist in database. One of them just retrieves data from one of the entities (this is achieved at this moment by the repository pattern) but adds an extra column to the final result, created and populated in the stored procedure.
I want to integrate the use of these stored procedures into my architecture. I've tried to add the stored procedures to my model, map it to the class and use it, but as I have to add an extra column to this entity in the model, I get an error that this field is not mapped.
Should I use my repository for this particular entity just for Add/Edit/Delete and create another entity with the extra field that will be used for just the Get action using the stored procedure?
Thanks.
Should I use my repository for this particular entity just for Add/Edit/Delete and create another entity with the extra field that will be used for just the Get action using the stored procedure
Depends on the use case? Sounds like it's used for a different case and if so I would create a new entity for it.
I have the below scenario. I am using EF 5 Code first, MVC 4 on VS 2010. I am using the Unit of Work and Repository pattern for my project.
I am not sure if this is possible or not. Kindly suggest.
I have a model class representing a database table. In the model class, I have a property that is decorated as [NotMapped]. I have a Stored Proc that returns data, similar to the model class. However, when I get the data in a List from the SP, it does not contain value for the [NotMapped] column (SP returns data for the [NotMapped] column though). This may be logically correct with respect to EF.
All I want to know is, do we have a way to get data populated for the [NotMapped] column. I want to achieve, CRUD using LINQ (excluding R - Read).
I would recommend to create a separate complex type for the stored procedure results. Otherwise sooner or later you will find yourself writing code to distinguish between entities coming from the DbSet or from the stored procedure. When the come from the stored procedure they can't be used in joins, for example. Or checks whether or not the unmapped property is set.
A very dirty approach could be to have two different contexts. With code first it is possible to have different contexts with different mappings to the same types, with and without the column ignored (if you use fluent mapping, not with data annotations). But that only succeeds if you tell EF not to check the database schema, so using migrations is ruled out as well. I would not do it!! For the same reason as I mentioned above. I would hate to have a type with a property that sometimes is and sometimes isn't set.
I did work on ADO.NET Entity Framework v2 about two years ago. I have faint memories.
Incidentally, I happen to be working in a very secured (for want of a euphemism) environment where a lot of links are blocked and there's not much one can do. It does get in the way of studying and working, more than a bit.
Therefore, I have to rely on this forum for a few basic questions I have to get started again. This time, I am working on Entity Framework 4. Here are my questions.
All these questions relate to the EDM generated entities, i.e. not the Code First model.
1) Is my understanding correct? I can rename any column name in the EDM designer generated model and nothing breaks.
2) Foreign keys are expressed as navigational properties in the generated entity classes. No special consideration is required to maintain foreign key relationships. I recall in version 1 of EF, you had just ID properties and the navigational IQueryable/IEnumerable/EntityCollection/RelatedEnd properties were introduced in version 2. I just need to know if I need to do anything to retain/maintain foreign key relationships and referential data integrity. I assume I don't need to. A confirmation would be nice.
3) What are all the possible ways to execute a stored procedure? I recall -- one way to use ExecuteSQL or something on the Context.Database object, another to use EntityClient API and the third was to specify stored procedure names in the InsertCommand, SelectCommand, etc. thingies in the mapping window of the EDM designer. Is this correct?
4) How do you use those SelectCommand thingies in the mapping window on an entity? Do you just supply the names of the stored procedures or user defined SQL functions?
5) How do I create an entity out of a subset of a table? Do I just create an entity from the table and then delete the columns I don't need from the designer? What happens if there are required (NOT NULL in SQL) values that are not in the subset I choose?
6) How do I create a table out of a query or join of two or more tables.
1) You can rename columns in the designer and nothing should break (if the name is valid)
2) Navigation properties point to related entities. In EF4 foreign keys were added. Foreign key properties basically expose the database way of handling relations. However, they are helpful since you don't have to load related entities just to change relationship - you can just change the key value to the id of the other entity and save your changes
3) Yes. You can either execute the procedure directly - this is for stored procedures that are not related to CUD (Create/Update/Delete) operations. You can map CUD operations to stored procedure as opposed to having EF execute SQL statements it came up with for your CUD operations.
4) I think this is a bit out of scope - you probably can find a lot of blogs with images how to do it. Any decent book on EF should also have a chapter (or two) on this. Post a question to stackoverflow if you hit a specific problem.
5) Remove properties in the designer and then supply default value to the S-Space definition. I believe you cannot do this with the designer. You need to rightclick on the edmx file and open it with the Xml editor and manually edit it. Also see this: Issue in EF, mapping fragment,no default value and is not nullable
6) You can either create a view in the database or you can create entity set using E-SQL in your edmx file (I think this will be read only though) or you may be able to use Entity Splitting. Each of these is probably a big topic itself so I think you should find more about these and come back if you have more specific questions / problems
i have a question about the reasonableness of using entity framework only with stored procedures in our scenario.
We plan to have an N-tier architecutre, with UI, BusinessLayer (BLL), DataAccessLayer(DAL) and a BusinessObjectDefinitions(BOD) layer. The BOD layer is known by all other layers and the results from executes queries in the DAL should be transformed into Objects (definied in the BOD) before passing into the BLL.
We will only use stored procedures for all CRUD methods.
So in case of a select stored procedure, we would add a function import, create a complex type and when we execute the function, we tranform the values of the complex type into a class of BOD and pass that to the BLL.
So basicly, we have no Entities in the Model, just Complex types, that are transformed into Business Objects.
I'm not sure if that all makes sense, since in my opinion, we lose a lot of the benefit, EF offers.
Or am i totally wrong?
I would not use EF if all I was just using was stored procs.
Personally, I'd look at something like PetaPoco, Massive or even just straight Ado.Net
EDIT
Here's an example of PetaPoco consuming SPs and outputting custom types
http://weblogs.asp.net/jalpeshpvadgama/archive/2011/06/20/petapoco-with-stored-procedures.aspx
I disagree with both of the existing answers here. Petapoco is great, but I think the EF still offers a number of advantages.
Petapoco works great (maybe even better than the EF) for executing simple stored procedures that read a single entity or a list of entities. However, once you've read the data and need to begin modifying it, I feel this is where the EF is the clear winner.
To insert/update data with petapoco you'll need to manually call the insert/update stored procedure using:
db.Execute("EXEC spName #param1 = 1, #param2 = 2")
Manually constructing the stored procedure call and declaring all the parameters gets old very fast when the insert/update stored procedures insert rows with more than just a couple of columns. This gets even worse when calling update stored procedures that implement optimistic concurrency (i.e. passing in the original values as parameters).
You also run the risk of making a typo in your in-lined stored procedure call, which very likely will not be caught until runtime.
Now compare this to the entity framework: In the EF I would simply map my stored procedure to my entity in the edmx. There's less risk of a typo, since the entity framework tools will automatically generate the mapping by analyzing my stored procedure.
The entity framework also will handle optimistic concurrency without any problems. Finally, when it comes time to save my changes the only step is to call:
entities.SaveChanges()
I agree, if you rely on stored procedures for all CRUD methods, then there is no need to use EF.
I use EF to map stored procedure calls as our DAL. It saves time in writing your DAL by mapping the functions. We are not using LINQ to SQL as much, as our DBA does not want direct data table access.