score:6

Accepted answer

several features of sql server are not supported by linq to sql:

  • batch updates (unless you use non-standard extensions);
  • table-valued parameters;
  • clr types, including spatial types and hierarchyid;
  • dml statements (i'm thinking specifically of table variables and temporary tables);
  • the output into clause;
  • the merge statement;
  • recursive common table expressions, i.e. hierarchical queries on a nested set;
  • optimized paging queries using set rowcount (row_number is not the most efficient);
  • certain windowing functions like dense_rank and ntile;
  • cursors - although these should obviously be avoided, sometimes you really do need them;
  • analytical queries using rollup, cube, compute, etc.
  • statistical aggregates such as stdev, var, etc.
  • pivot and unpivot queries;
  • xml columns and integrated xpath;
  • ...and so on...

with some of these things you could technically write your own extension methods, parse the expression trees and actually generate the correct sql, but that won't work for all of the above, and even when it is a viable option, it will often simply be easier to write the sql and invoke the command or stored procedure. there's a reason that the datacontext gives you the executecommand, executequery and executemethodcall methods.

as i've stated in the past, orms such as linq to sql are great tools, but they are not silver bullets. i've found that for larger, database-heavy projects, l2s can typically handle about 95% of the tasks, but for that other 5% you need to write udfs or stored procedures, and sometimes even bypass the datacontext altogether (object tracking does not play nice with server triggers).

for smaller/simpler projects it is highly probable that you could do everything in linq to sql. whether or not you should is a different question entirely, and one that i'm not going to try to answer here.

score:0

if you already have tested and working stored procedures, why convert them at all? that's just making work for no reason.

if you were starting a new product from scratch and were wondering whether to use stored procedures or not, that would be an entirely different question.

score:1

what does this mean? does this mean you want to use l2s to call your stored procedures, or do you want to convert all the t-sql statements in your stored procs to l2s? if it's the later, you should not have too many problems doing this. most t-sql statements can be represented in linq without problem.

i might suggest you investigate a tool like linqer to help you with your t-sql conversion. it will convert most any t-sql statement into linq. it has saved my quite a bit of time in converting some of my queries.

score:1

there are many constructs in t-sql which have no parallel in linq to sql. starting with flow control, ability to return multiple row sets, recursive queries.

you will need to approach this on a case by case basis. remembering any times the sp does significant filtering work on the database much of that filtering may end up on the client, so needing to move far more data from server to client.

score:2

i'm not a fan of this approach. this is a major architectural change, because you are now removing a major interface layer you previously put in place to gain a decoupling advantage.

with stored procedures, you have already chosen the interface your database exposes. you will now need to grant users select privileges on all the underlying tables/views instead of execute on just the application stored procedures and potentially you will need to restrict column read rights at the column level in the tables/views. now you will need to re-implement at a lower level every explicit underlying table/view/column rights which your stored procedure was previously implementing with a single implicit execute right.

whereas before the services expected from the database could be enumerated by an appropriate inventory of stored procedures, now the potential database operations are limited to the exposed tables/views/columns, vastly increasing the coupling and potential for difficulty in estimating scope changes for database refactorings and feature implementations.

unless there are specific cases where the stored procedure interface is difficult to create/maintain, i see little benefit of changing a working sp-based architecture en masse. in cases where linq generates a better implementation because of application-level data coupling (for instance joining native collections to database), it can be appropriate. even then, you might want to linq to the stored procedure on the database side.

if you chose linq from the start, you would obviously have done a certain amount of work up front in determining column/view/table permissions and limiting the scope of application code affecting database implementation details.

score:4

i've found that in almost all cases where i've done a new project with l2s, i've completely removed the need for stored procedures. in fact, many of the cases where i would have been forced to use a stored proc, multivariable filters for instance, i've found that by building the query dynamically in linq, i've actually gotten better queries in the vast majority of cases since i don't need to include those parts of the query that get translated to "don't care" in the stored proc. so, from my perspective, yes -- you should be able to translate your stored procs to linq.

a better question, thought, might be should you translate your stored procs to linq? the answer to that, i think, depends on the state of the project, your relative expertise with c#/vb and linq vs sql, the size of the conversion, etc. on an existing project i'd only make the effort if it improves the maintainability or extensibility of the code base, or if i was making significant changes and the new code would benefit. in the latter case you may choose to incrementally move your code to pure linq as you touch it to make changes. you can use stored procs with linq so you may not need to change it to make use of linq.


Related Query

More Query from same tag