Where I work it is a requirement for us to go through stored procedures as a mechanism to access our data through code. I am using LINQ2SQL to minimize this pain so that I can work with objects instead of ADO.NET directly. I have a situation Linq2SQL is consuming one of my stored procedures an generating code where the return type from the stored proc call is an int. The stored procedure actually returns a dataset. After doing a little research I have found that this is because the SQLClient library can not properly parse the sproc to generate the expected metadata that Linq2SQL uses to create the object graph. My question is how can sprocs (even complex ones) be structured so that you get an object graph out of linq2sql, or in other words what should you avoid having in your stored procedure that will create confusion for the SQLClient library to not understand how to generate the metadata that linq2sql consumes in order to create an object graph?
This is not actually a limitation of LINQ to SQL but rather of SQL Server which can not always tell a client what the return type would be without actually running it when it contains temporary tables, cursors or dynamic SQL.
As running it with invalid parameters could be potentially catastrophic it doesn't try.
You can either set it by hand using the designer or if it is absolutely okay to run the stored procedure with invalid data (i.e. it is purely passive) then you can add SET FMTOPT OFF to the start of the stored procedure.
DamienG works on the LinqToSql team at Microsoft and I have upvoted his answer as correct.
That said, he likely won't advise you away from LinqToSql and I think it's very important to consider that option.
Trying to guess the return type of a stored procedure is very difficult and LinqToSql does it as well as anyone (for SQL Server). That said, there are very compelling reasons not to use stored procedures:
Stored procedures are bad, m'kay?
If you must protect your tables from developers for "security reasons" (which I'm guessing is the situation you are in), it's best to do that with views instead of stored procedures.
If you are using views, you then have a lot better options in the ORM department than LinqToSql.
The main problem you are going to run into with LinqToSql in this regard is that what works fine for 5 stored procedures in a tiny database doesn't work fine for 50 or 500 stored procedures. You can use the O/R Designer to "override" the return type of a stored procedure, but you will have significant syncing issues when stored procedures or the tables, etc. they operate on change. Changes to stored procedures will not get reflected in the O/R Designer unless you remove the stored procedure from the O/R Designer, re-add it, and then reapply your custom override. If your project is like any normal project, the tables and stored procedures change often and this sync issue soon becomes a nightmare because it's completely manual and if you fail to do it correctly you will get very strange errors at runtime.
I would strongly advise against continuing down the path you are on.
Related
I've tried searching and can't find any type providers for databases other than the linq one which spits out the connected object types with all the linq information embedded in them.
Was hoping there might be a type provider for SQL databases that spits out a dumb DTO, or if not, a library that will automatically convert them or some such for me so I get the benefits of all the generated types I need, without having to manually created dumb DTOs where I want to have no linq to sql references outside of my repository.
Fsharp.Data.SqlClient sounds like what you are looking for. It generates tuples or custom record-like DTOs, and supports Stored Procedures and table-valued UDFs as well. SQL 2012 only though.
i am using stored procedure and if i add/remove parameters (in the sproc) than when i come to see in dbml than i dont see any changes so what i am doing currently is remove the sproc and added back to dbml designer.
is this a normal behaviour of linqtosql?
in the future if i end-up modify the sproc for some reason do i need to end-up updating dbml also ?
There are a couple of ways of generating Linq To SQL classes from a database, neither of which offers round-trip coding or live update. If you change your database, including sprocs, then you'll need to regenerate your Linq to SQL classes.
I'm working on a project where most of the times I'm going to call database with a stored procedure and I'm a little bit confused what should I do. Options are not just restricted to Sql to Linq and EF. If there are any better options please suggest them too.
UPDATE - Reason for using SPs
I've to apply logic in many of the stored procedure. Apart from this, my intention to use SPs for CRUD operation is to improve performance.
Thanks in advance.
ORM tools wasn't designed to be used only with stored procedures (but they could), it will be very difficult to map data on eneities and perform all operations using EF. You can relay on this guide, but I need some details to suggest something more meaningfull.
I'll just put it out there that I'm new to LINQ to SQL. Hell, i'm relatively new to programming in general.
Anyways, I would like to learn and use LINQ to SQL to a project that was built using .NET 2.0 Framework. The project uses stored procedures to access the database (there's no dynamic SQL queries on the front end servers). LINQ to SQL seems a great alternative to stored procs but to introduce it to my project would break the principle of 'Separation of Concern'. Would it be best to not break this principles and just write more stored procedures when needed? Or is there a way to use LINQ to SQL without breaking the principle?
I generally find it hard to add new technology and tools in legacy projects without breaking the consistencies in projects.
Having code which interacts with the database server through SQL instead of through stored procedures is not a violation of separation of concerns, as long as that code is well modularized and the LINQ to SQL part cares only about data entry/retrieval and is not intermingled with other tasks (concerns). LINQ to SQL usage does not break any principle
Now, modifying code not to use SPs when it has been coded that way from the beginning will probably not be a small task and there might not be any real benefit in the end other than you learning LINQ to SQL.
Actually, LINQ to SQL helps a great deal with SoC. It separates the fact that you are using SQL from your domain objects even more than a traditional sproc-based DAL. Having a bunch of methods which call into stored procedures is a poor-man's attempt at the same thing - minimizing but not eliminating contact points between the DAL and the business logic. The LINQ to SQL library becomes your DAL, and you're free to manipulate a bunch of stupid objects with no direct ties to any data backing - with the added benefit of being able to express directly against your domain objects using LINQ expressions, instead of relying on the pre-determined permutations of stored procs.
If the project is a large one and uses many sprocs then it is not a smart idea to replace it's sprocs with LINQ. The reasons should be obvious why it is not prudent to do so. However, moving forward, this in no wise means you shouldn't implement a layer for LINQ. This is what I have done with some of my larger legacy apps. Implementing and using LINQ is well worth the effort, but it is not worth the effort (nor worth the risk) to rewrite old sprocs to use LINQ.
I have a Client/Server application, where the Client and Server have some common tables (which are kept in synchronisation as part of the application).
We currently store these tables (i.e. FileDetails) in a Shared.dbml file. Until now, any stored proc that returns a result of set of FileDetails, has been placed in the Shared.dbml (even it is a Server-only) SP.
I released that the LINQ to SQL supports a Base Class property on the DBML, and I thought that perhaps I could have a Server.dbml, that extends my Shared.dbml. In theory this would give me a ServerDataContext with all the shared tables and SPs, as well as the server-specific elements. Normally in the SQL designer I would drag and drop the SP, over the FileDetails table to show this is what was returned, however as the class is in a different DBML this is not possible, and in the XML I don't think the ElementType IdRef="1" approach will work (as the ref needs to point to another file)
I found I can get around that problem by editing the XMLs return type manually:
<Function Name="dbo.SELECT_FTS_FILES" Method="SELECT_FTS_FILES">
<Return Type="ISingleResult<DataTypes.FileDetails>" />
</Function>
My question is, does anyone have any experience with this kind of approach, and could point me to further resources? Are there any obvious drawbacks to it (other than than manual XML updates)
All feedback welcome
You could inherit from your datacontext. However in your new datacontext you wouldn't be able to use the linq designer you would have to code things out manually.
Is there any reason you don't want two datacontext?
Inheritance and LinqToSql don't play nice together in general. If you have a deep need for it you should look into another ORM like NHibernate.