Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
00kevin
Yak Posting Veteran
78 Posts |
 Posted - 2009-11-24 : 16:47:19
|
| Anyone here having problems with developers who are creating their applications using LINQ?I'm having a hard time understanding why anyone would want to use LINQfor an enterprise level system. Up until recently most experienced developers would insist on high security and only allow applications to interface with the database via stored procedures. Sadly, there are now people who insist that TSQL is a thing of the past and the Relational Languages are way of the future.The other day I had a discussion with a LINQ developer regarding the fact that his website was opening and closing a connection over 300 times per page. I told him that it was very bad programing to allow that many connections to be opened. I tried to tell him that he should only be opening the connection once for each of his pages. His rebuttal was that with SQL server connection pooling this isn't problem. How do I tell this guy he is completely wrong and that he shouldn't be abusing the connection pool. What I need are hard facts against this kind of programing. I've searching around the net looking for good reasons, but I haven't found anything good yet. |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
|
|
blindman
Master Smack Fu Yak Hacker
2365 Posts |
Posted - 2009-11-25 : 13:43:05
|
quote:
Originally posted by 00kevin
Anyone here having problems with developers who are creating their applications using LINQ?
Yesquote:
Originally posted by 00kevin
I'm having a hard time understanding why anyone would want to use LINQ for an enterprise level system.
1. Laziness.2. Inability to write SQL.3. Fear of stored procedures.4. General lack of concern for any issues that will crop up after they roll off the project.quote:
Originally posted by 00kevin
Sadly, there are now people who insist that TSQL is a thing of the past and the Relational Languages are way of the future.
Think of the brisk business we will do rewriting this crap three years from now.quote:
Originally posted by 00kevin
The other day I had a discussion with a LINQ developer regarding the fact that his website was opening and closing a connection over 300 times per page.
Seen this too many times.quote:
Originally posted by 00kevin
How do I tell this guy he is completely wrong and that he shouldn't be abusing the connection pool.
What makes you think he cares? (See answer #4 to question #2 above...)________________________________________________If it is not practically useful, then it is practically useless.________________________________________________ |
 |
|
|
Ifor
Aged Yak Warrior
700 Posts |
Posted - 2009-11-26 : 07:32:26
|
| 1. LINQTry and get agreement from your managers that access to the DB from applications should only via SPs. (Security, ease of maintenace etc) LINQ can use SPs so your developers can use LINQ and access the DB via SPs.2. WebsiteThe pages on an enterprise website should not be directly accessing the DB. They should interact with the Business layer which in turn should interact with a Data Access or Persistence layer. The simplest way to work with .Net is to have a Data Access layer and pass DataSets betweeen the layers. If you write the Data Access Layer and the SPs then the developers do have to worry about the DB. |
|
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
Posted - 2009-11-26 : 07:40:41
|
| first of all LINQ is a valid ORM.the reason you shouldn't really use it for serious enterprise dev is that it's a deadend tech as far as Microsoft is concerned. they've put all their efforts into Entity framework.so there's you valid business reason.LINQ sends parametrised queries to the db.what you want to query is decided by the data context which you can set.the main problem i see is that you can't change the underlying SQL and optimize it if needed but that's the problem of all ORM's and that's why almost all of them have sproc support.as for the argument that you can't build enterprise level apps with linq that's just not true. just look at the whole StackExchange websites with thier leader StackOverflow.comopening a connection 300 times is just piss poor programming practice. tell them to run linq2sql profiler by Ayende and then they can see all the SELECT N+1 warnings they get.___________________________________________________________________________Causing trouble since 1980Blog: http://weblogs.sqlteam.com/mladenpSpeed up SSMS development: www.ssmstoolspack.com <- version 1.7 out! |
|
|
|
00kevin
Yak Posting Veteran
78 Posts |
Posted - 2009-11-26 : 13:31:25
|
| Some have suggested that the LINQ to Entity Framework is a much better approach. With this I would have to strongly disagree.This approach ends up making the database a simple storage device where the only objects used are tables. The Entity Framework isn't an improvement at all. Now developers are defining data relationships in their applications and storing all the code in xml files (which is a pain to maintain).Furthermore, the .Net Entity framework does not support stored procedures that return values. |
|
|
|
afrika
Master Smack Fu Yak Hacker
2706 Posts |
Posted - 2009-11-26 : 18:00:41
|
| I had similar thoughts.I once was shortlisted for a contract to develop an application in .net, but along the line. they asked if i used LINQ and SQL Metal and if i was wiling to work with it, and i said no. So I lost out.I try to learn new technologies every now and then, e.g. AJAX and now starting on WPF using C# and MVC.I had posted some questions about the topic herehttp://www.sqlteam.com/forums/topic.asp?TOPIC_ID=135073andhttp://forums.asp.net/t/1486713.aspxMaybe, Microsoft wants to have an "ALL ROUND ROBUST" Framework for its .net framework. As I once spoke to a java developer, that said they werent looking to using .net yet because it lacked a few features they needed. This was back in 2007 |
|
|
|
|
|
|
|
|
Linq vs TSQL