I'm looking for the most elegant way of making Entity Framework call my stored procedures (delete, insert & update). The catch is that I use database-first, I can't change the stored procedures and there are more arguments to the stored procedures than there are columns in the related table. Id rather not use functional imports since they have to be called by my code, and not by the framework. It doesn't feel elegant enough.
There is a nice solution for Linq to SQL. The code generator gives me Insert( instance) (and Delete, Update) partial methods that are called by the framework if I implement them in a partial class. From that method I just have to call this.() with the instance variables and then add my extra arguments.
What is the easiest and most elegant way of doing this in Entity Framework?
/BE
As far as I am aware, you can't - if you can't change the stored procedures, then ExecuteFunction or a function import is your only option. I would dearly love to be proved wrong though.
Have you considered creating new stored procedures in the form EF wants, and calling the existing SPs from them?
Related
I have two questions for database handling using Entity Framework. I am using SQL Server 2012/14 web api 2 (VS 2012/13) but it doesn't matter because my question is regarding code first approach for EF6. In code first approach if the table does not exist that EF creates it for you (EF's awesome feature).
1.) Usually when EF creates a table, it uses nvarchar for string datatype but I need to use varchar. How can I specify that in EF? (Also for other datatypes?)
2.) Also I need to create stored procedure using EF (if it does not exist in DB). And also how can I invoke it from EF? Stored Procedure takes input parameter and gives output records.
In case of any change in model or logic, it should be reflected automatically in DB. [Very Important]
Request: Please keep the understanding level of your explanation to be Super Easy. I have just saw some YouTube videos and trying to understand it and implement it on my project. But I don't want to just copy code, I want to understand it so please kindly provide explanation for each line. Multiple solution will be appreciated. (I mean Data Annotation and Fluent API both)
My Last Option: I was thinking of creating script and executing it in "up" function (where migration happens and creates all SQL object) But issue with that approach is that if there is any change in my model, I have to reflect the same changes in that script too as it is hard coded. I am going to use this option when I have no other choice left. I haven't tried this option yet so I might be completely wrong about it.
Thanks in advance.
1) If you want to specify the database type to be used in the actual column of your table, here is the code (using Fluent API) for it:
modelbuilder.Entity<Department>()
.Property(p => p.Name)
.HasColumnType("varchar");
Source: https://msdn.microsoft.com/en-us/data/jj591617#1.10
2) If you want Entity Framework to generate the script that would create your desired stored procedure, have a look at this article: https://msdn.microsoft.com/en-us/data/dn468673. I don't think it would be a good idea to copy the source code from there and paste it over here, so if you have any specific questions, feel free to ask.
If you want to create the stored procedure script yourself and then invoke it using Entity Framework, then have a look at this article: https://msdn.microsoft.com/en-us/data/jj557860. Note: this option tends to have a maintenance cost associated to it. But it is worth doing it if the stored procedure generated by Entity Framework is not as efficient as your version of how the stored procedure should be written as.
Again please feel free to ask any specific questions here.
When I am developing an ASP.NET website I do really like to use Entity Framework with both database-first or code-first models (+ asp.net mvc controllers scaffolding).
For an application requiring to access an existing database, I naturally thought to create a database model and to use asp.net mvc scaffolding to get all the basic CRUD operations done in a few minutes with nearly no development costs.
But I discussed with a friend who told me that accessing data stored in the database only through stored procedures is the best approach to take.
My question is thus, what do you think of this sentence? Is it better to create stored procedures for any required operations on a table in the database (e.g. create and read on this table, update and delete only on another one, ...)? And what are the advantages/disadvantages of doing so instead of using a database-first model created from the tables in the database?
What I thought at first is that it double costs of development to do everything through stored procedures as you have to write these stored procedures where Entity Framework could have provided DbContext in a few clicks, allowing me to use LINQ over Entities, ... But then I've read a few stuff about Ownership Chains that might improve security by setting only permissions to execute stored procedures and no permissions for any operations (select, insert, update, delete) on the tables.
Thank you for your answers.
Its a cost benefit analysis. Being a DB focused guy, I would agree with that statement. It is best. It also makes you code easier to read (no crazy sql statements uglifying it). Increased performance with cached execution plans. Ease of modifying the querying without recompiling the code, eetc.
Many of the ppl I work with are not all that familiar with writing SPROCs so it tends to be a constant fight with them use them. Personally I dont see any reason to ever bury SQLStatments in your code. They tend to shy away from them b/c it is more work for them up front.
Yes, it's a good approach.
Whether it's the best approach or not, that depends on a lot of factors, some of them which you don't even know yet.
One important factor is how much furter development there will be, and how much maintainence. If the initial development is a big part of the total job, then you should rather use a method that gets you there as fast and easy as possible.
If you will be working with and maintaining the system for a long time, you should focus less on the initial development time, and more on how easy it is to make changes to the system once it's up and running. Using stored procedures is one way to make the code less depending on the exact data layout, and allows you to make changes without a lot of down time.
Note that it's not neccesarily a choise between stored procedures and Entity Framework. You can also use stored procedures with Entity Framework.
This is primarily an opinion based question and the answer may depend on the situation. Using stored procedure is definetely one of the best ways to query the database but since the emergence of Entity Framework it is widely used. The advantage of Entity Framework is that it provides a higher level of abstraction.
Entity Framework applications provide the following benefits:
Applications can work in terms of a more application-centric conceptual model, including types with inheritance, complex members,
and relationships.
Applications are freed from hard-coded dependencies on a particular data engine or storage schema.
Mappings between the conceptual model and the storage-specific schema can change without changing the application code.
Developers can work with a consistent application object model that can be mapped to various storage schemas, possibly implemented in
different database management systems.
Multiple conceptual models can be mapped to a single storage schema.
Language-integrated query (LINQ) support provides compile-time syntax validation for queries against a conceptual model.
You may also check this related question Best practice to query data from MS SQL Server in C Sharp?
following are some Stored Procedure advantages
Encapsulate multiple statements as single transactions using stored procedured
Implement business logic using temp tables
Better error handling by having tables for capturing/logging errors
Parameter validations / domain validations can be done at database level
Control query plan by forcing to choose index
Use sp_getapplock to enforce single execution of procedure at any time
in addition entity framework will adds an overhead for each request you make, as entity framework will use reflection for each query. So, by implementing stored procedure you will gain in time as it's compiled and not interpreted each time like a normal entity framework query.
The link bellow give some reasons why you should use entity framework
http://kamelbrahim.blogspot.com/2013/10/why-you-should-use-entity-framework.html
Hope this can enlighten you a bit
So I'm gonna give you a suggestion, and it will be something I've done, but not many would say "I do that".
So, yes, I used stored procedures when using ADO.NET.
I also (at times) use ORM's, like NHibernate and EntityFramework.
When I use ADO.NET, I use stored procedures.
When you get data from the database, you have to turn it into something on the DotNet side.
The quickest thing is to put data into a DataTable or DataSet.
I no longer favor this method. While it may make for RAPID development ("just stuff the data into a datatable")......it does not work well for MAINTENANCE, even if that maintenance is only 2-3 months down the road.
So what do I put the data into?
I create DTO/POCO objects and hydrate the data from the database into these objects.
For example.
The NorthWind database has
Customer(s)
Order(s)
and OrderDetail(s)
So I create a csharp class called Order.cs, Order.cs and OrderDetail.cs.
These ONLY contain properties of the entity. Most of the time, the properties simple reflect the columns in the database for that entity. (Order.cs has properties, that simulate a Select * from dbo.Order where OrderID = 123 for example).
Then I create a child-collection object
public class OrderCollection : List<Order>{}
and then the parent object gets a property.
public class Customer ()
{
/* a bunch of scalar properties */
public OrderCollection Orders {get;set;}
}
So now you have a stored procedure. And it gets data.
When that data comes back, one way to get it is with an IDataReader. (.ExecuteReader).
When this IDataReader comes back, I loop over it, and populate the Customer(.cs), the Orders, and the OrderDetails.
This is basic, poor man's ORM (object relation mapping).
Back to how I code my stored procedures, I would write a procedure that returns 3 resultsets, (one db hit) and return the info about the Customer, the Order(s) (if any) and the OrderDetails(s) (if any exist).
Note that I do NOT do alot of JOINING.
When you do a "Select * from dbo.Customer c join dbo.Orders o on c.CustomerID = o.CustomerId, you'll note you get redundant data in the first columns. This is what I do not like.
I prefer multiple resultsets OVER joining and bringing back a single resultset with redundant data.
Now for the little special trick.
Whenever I select from a table, I always select all columns on that table.
So whenever I write a stored procedure that needs customer data, I do a
Select A,B,C,D,E,F,G from dbo.Customer where (......)
Now, alot of people will argue that. "Why do you bring back more info than you need?"
Well, real ORM's do this anyway. So I am poor-man reflecting this.
And, my code for taking the resultset(s) from the stored procedure to turn that into instances of objects........stays consistent.
Because if you write 3 stored procedures, and each one selects data from Customer table, BUT you select different columns and/or in a different order, youre "object mapper" code needs to have a method for each stored procedure.
This method of ADO.NET has served me well.
And, once my team swapped out ADO.NET for a real ORM, and that transition was very pain free because of the way we did the ADO.NET from the get go.
Quick rules of thumb:
1. If using ADO.NET, use stored procedures.
2. Get multiple result-sets, instead of redundant data via joins.
3. Make your columns consistent from any table you select from.
4. Take the results of your stored procedure call, and write a "hydrater" to take that info and put into your domain-model as soon as you can. (the .cs classes)
That has served me well for many years.
Good luck.
In my opinion :
Stored Procedures are written in big iron database "languages" like PL/SQL or T-SQL
Stored Procedures typically cannot be debugged in the same IDE your write your UI.
Stored Procedures don't provide much feedback when things go wrong.
Stored Procedures can't pass objects.
Stored Procedures hide business logic.
Source :
http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html
I am looking for some guidance on how to tweak the T4 code generation of the entity classes in EntityModel.tt and possibly EntityModel.Context.tt (I'm using POCO classes) to force any queries on entities to use stored procedures (I already have the EntitySQL.tt generating all my Stored procedures)
For example, something like
context.MyEntities().Single(c => c.id == 5)
Would not generate SQL, but would call the SP `sp_GetMyEntities'
If you have a better strategy for achieving the same result I would be glad to learn about it.
UPDATE
At this point I'm interested only in the READ part of CRUD. And there are no joins. Just simple loading of a single entity by ID. Theoretically the SP can be set to accept the ID of the loaded item as a parameter, to avoid loading the whole table (in this case there will be bn need for the .Single(c => c.id == 5) part and ID will be provided to the MyEntities object.
This is for a "database first" implementation
Code first does not support mapping to stored procedures. Model first and Database first flows do support mapping to stored procedures but it does not work the way you would like to use it since stored procedures are not compoosable (i.e. if you do .Single() the filtering will happen at best on the client not in the database - for performance reasons you want the filtering to happen on the database site since you probably don't want to bring the whole database to the client just to select one entity). Core libraries of Entity Framework 5 that ship with .NET Framework 4.5 support TVFs which are composable and should make it possible what you are after but again not in code first scenarios.
My scenario
I'm using Visual Studio 2010 with Entity Framework 4.1
I have a legacy database with many tables and many stored procedures.
I'm writing an ASP.NET C# program using MVC 3
I have adopted the 'database first' design using ADO.NET DbContext so I have an edmx with all the models and associations and navigation properties nicely set up.
I can map the insert, update, delete procedures to the relevant models.
I've used 'Function Import' to import other stored procedures.
However, I can't find a way to map my Select procedures to select actions (select by id, select list, select by filter etc).
EF seems to use lazy loading so what I want to happen is when an object fetches its child objects it uses the stored procedures already written.
(The select procedures take into account an 'IsDeleted' flag, and use the 'ORDER BY' clause, amongst others)
I see from this article
http://weblogs.asp.net/scottgu/archive/2007/08/16/linq-to-sql-part-6-retrieving-data-using-stored-procedures.aspx
that Linq to SQL allows drag and drop of SPs, which sounds, more or less, exactly what I want.
I've also come across the term DefiningQuery.
http://msdn.microsoft.com/en-us/library/cc982038.aspx
Is this what I want? I don't like the note 'Any changes made to the storage model, including defining queries, will be overwritten when you run the Update Model Wizard.'
In summary, what I want to happen is when an object fetches its child objects it uses my stored procedures.
Can I achieve my goal using Entity Framework?
Have I missed something obvious?
Or should I try to be really clever and modify the db Entity T4 template, so that, for example, my generated Address model has this property:
public virtual ICollection<AddressLine> AddressLines {
get{
DBWrapper _db = new DBWrapper();
return _db.GetAddressLines(AddressID);
}
set{};
}
where GetAddressLines is custom function that calls a function import and does the neccessary conversions.
It is not possible. You can import your stored procedures as function imports and manually execute them but you cannot replace queries generated by EF with custom stored procedures.
Except that you can, sort of.
Take your most basic select stored procedure (i.e., the one which is closest to "select * from mytable", and use it to define a view in your database. Have entity framework use this "myview" instead of "mytable". Then map your insert, update and delete stored procs for this view-based entity as you did originally for your table.
Finally, use function imports for your more selective selects, and define them to return collections of your entity. So if you had something like a Person entity, and you had a stored proc called something like FetchPersonByAge(int), your entity would end up with a static method called something like "GetByAge(int)". You could then call it in code like this: var people33 = Person.getByAge(33);
I have done this, and it worked quite well, allowing me to respect a legacy database's designers demand that all database access be through their stored procs, and no user code directly accessing tables. See Julie Lerman's article:
http://msdn.microsoft.com/en-us/data/gg699321.aspx
Dave
By edict, we're using stored procedures for all interactions with our database.
By organizational directive, we're using table value parameters in some of these stored procedures, specifically the ones I need to use.
By legal edict, we can't use nHibernate or anything under LGPL (though, if necessary, we can fight back on that).
Are there any OR/M (object-relational mapper) frameworks out there that support table value parameters into stored procedures?
I've already investigated the crap out of Linq to Sql and Entity Framework v1, and I know that it's fundamentally not supported now, and L2Sql will probably never support it.
Anything out there, commercial or free? I really don't want to write hundreds of lines of boilerplate to decode the results.
So, write your own, at least for these stored procedures.
Are there so many of them?
It's way to late for me to try this, but you can: take one of your stored procedures. Create a new typed DataSet in Visual Studio. Drag this SP from Server Explorer onto the design surface. See whether the parameters collection is correctly updated.
I'm not suggesting this as your ORM technology, only as an experiment to see whether table-valued parameters are supported by this designer (and, presumably by the designer for SqlCommand, SqlDataAdapter, etc).
If it works, then it gives you at least a bad way of quickly generating the code you'd need in an ORM: copy the code from the dataset.designer.cs file into your own code.
It's then possible, if you really need to know, to figure out what the DataSet Designer is using to pick up the parameters - you could then use it yourself, in your own code generation.