Accepted answer

I don't see the value in moving to LINQ here. The beauty of LINQ is that you can write your query in the language of your domain objects, rather than in T-SQL. In your case you only want to accept actual SQL commands. It seems like it would be more work to deconstruct the command, turn it into LINQ -- using reflection to identify the appropriate tables in the data context -- and then execute the query only to print out the properties of the resulting objects.


You can add stored procedures to your database, and then add them into linq. Linq provides nice code generation to deal with your stored procedures getting and returning rows using deferred execution.

If you have a dynamic query that you wish to execute that isn't a stored procedure then you will need to either stick with ADO.Net or learn how to express your query in LINQ. Perhaps if you provide the query we could help you do this with your data context.

PS. When we moved to LINQ I found that the amount of boilerplate ADO.Net code we had to write dropped dramatically. I wrote my SPRoc mapped it to sql and used it straight away :).


There is Dynamic LINQ by Scott Gu which can be found here but as tvanfosson has already said you really aren't going to solve much with moving to Linq and most likely is more effort then result.

Related Articles