I have always been using nhibernate ORM for inserting data to sql tables from application.
But recently I tried reading on Ado.net and found suggestion to use stored proc instead of
sqlcommand.executenonQuery().
In that case, every table insertion will need a different stored proc . A 100 table application will need 100 Stored procs. Is my understanding correct or is there a better way of doing it in a more generic way?
Please suggest.
A simple one-liner command can be an INSERT given directly in .NET code via parameterized Command class. Something like:
using (SqlConnection sqlConn = new SqlConnection(connectionString)) {
using (SqlCommand sqlCmd = new SqlCommand("INSERT INTO MyTable (Field1, Field2) VALUES (#Param1, #Param2)", sqlConn)) {
sqlCmd.Parameters.AddWithValue("#Param1", someValue1);
sqlCmd.Parameters.AddWithValue("#Param2", someValue2);
sqlConn.Open();
sqlCmd.ExecuteNonQuery();
}
}
So it doesn't have to be a stored proc for every command. You can have a class or classes dedicated to DB access only (db access layer) and populate it with various methods to read/write from DB. You can even have a generic method that automatically derives parameters for INSERT/UPDATE commands.
Of course if it's more than 1-2 commands or some logic is involved - that asks for a stored procedure.
Btw, this is my personal opinion, but i think ORMs are evil.
Have you heard about dapper, a powerful tool to execute a query and map the results to a strongly typed List. Dapper also support stored procedures, check this out.
Example:
dbConnection.Query<return type>("yourSP", parameters,
commandType: CommandType.StoredProcedure).First();
Also take some time to check this SO question.
Personally I would use an ORM if I have more than 5 different tables to select and/or insert into. Why should you walk 100 miles if the bus stop is right infront of the door?
That said the ORM is a generic way to access data. If you would want to code everything by hand, you could surely write stored procedures with optional parameters, but I don't recomend it.
Related
I'm moving from EF Core 2.2 to 3.1. One breaking change (#15392) was that it no longer composed over stored procedures, so you had to add 'AsEnumerable'. That usually works, but I have a stored procedure call on a TPH table where that fails:
My call to the SPROC is:
SqlParameter authorizedUserID_p =
new SqlParameter("#authorizedUserID", authorizedUser.ID);
IEnumerable<Post> query =
context.Posts.FromSqlRaw<Post>("Post.USP_ReadPost #ID, #AuthorizedUserID",
parameters: new[]{ parentID_p, authorizedUserID_p }
).AsEnumerable<Post>();
Post targetPost = query.ToList<Post>().FirstOrDefault<Post>();
And it produces this error, recommending using AsEnumberable (which I'm already using above):
System.InvalidOperationException: FromSqlRaw or FromSqlInterpolated was called with non-composable SQL and with a query composing over it.
Consider calling AsEnumerable after the FromSqlRaw or FromSqlInterpolated method to perform the composition on the client side.
I believe the reason is because my Posts table is Table-per-hiearchy, as other calls to SPROCS in the same application are working fine. Would appreciate any help possible!
This is yet another issue introduced by EFC 3, tracked by #18232: Impossible to use stored procedures related to entities that inherits another one.
The reason is that SP calls are not composable, and EF Core always try to compose SQL for TPH base entities in order to add discriminator condition. Similar to Global Query Filters, but there you can at least use IgnoreQueryFilters, while here you have no option.
The good news is that it's already fixed in EFC repository. The bad news is that it won't be released until EFC 5.0.
Since AsEnumerable() doesn't help, all you can do is to wait for EFC 5.0. Or, if possible, convert SPs like this to TVF (table valued functions) which are composable. In general, use scalar functions or stored procedures with output parameter(s) for non query returning calls (to be executed with ExecuteSql*), and table valued functions for single query returning calls (to be used with FromSql*). Note that currently EFC does not support multiple query returning stored procedures anyway.
My question is that how to call a function in LINQ query? e.g
source.Where(x=> double.Parse(x.Col1)==3)
or
source.Where(x=> AnyUserFunction(x.Col1)==true)
Basically my requirement is to check weather Col1 is a numeric value or not, but I occasionally need to call my User Defined functions as well.
The problem is that your Linq to Entities provider doesn't know how to translate your custom methods to SQL. The solution proposed by #teovankot is the easy way to solve this problem, but if you want to work with Linq to Objects I suggest you use AsEnumerable extension method instead ToList because AsEnumerable does not execute the query until you consult the data, it preserves deferred execution, but be careful, try to don't use AsEnumerable or ToList on the entire DbSet because you'd retrieve all rows of that table affecting your application's performance.
Now if you only want to check weather Col1 is a numeric value or not, another solution could be using SqlFunctions.IsNumeric method which is translated into native SQL:
using System.Data.Entity.SqlServer;
//...
source.Where(x=> SqlFunctions.IsNumeric(x.Col1)==1);
You can find another set of functions you can also call in the DbFunctions static class.SqlFunctions are SQL Server specific, whereas DbFunctions aren't.
You can't call user defined functions easy in linq to sql.
But you can do it after you get all your data from DB to your server. Like this:
source.ToList().Where(x=> AnyUserFunction(x.Col1)==true)
Note ToList() call. this will get all your data from DB so you basically working with linq to objects where you can easy use your user defined fucntions.
Is there a performance difference when executing stored procedures from Entity Framework? I tried to do some testing, but I get similar results, so I want to make sure I decide to use better approach.
One way it to add the stored procedure in EDM, and second way is to call
content.Database.SqlQuery("sp_Name", params)
http://www.entityframeworktutorial.net/EntityFramework4.3/execute-stored-procedure-using-dbcontext.aspx
I am trying to learn and start using entity framework 5.0
I was able to create my data model (Only one table), but I am not able to find the commands / functions / methods that allow me to send sql queries and access the results and save and update...etc. Can someone write a very small block of code to show how to do so?
You can write raw SQL like so to return entities:
var entities = context.MyEntities.SqlQuery("SELECT * FROM dbo.MyEntities").ToList();
Or for non entities:
var myAttributeValues = context.Database.SqlQuery<string>(
"SELECT MyAttribute FROM dbo.MyEntities").ToList();
However, you should not use raw sql just because you prefer it. You should use it in situations where raw sql provides you with an advantage over generated queries. If you prefer to write SQL then you should reconsider whether you really want to use EF or any other ORM at all. See here for some EF documentation and examples and here for info on querying for entities.
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.