Statement about LINQ
-
Okay, so I don't know very much about LINQ but our IT head brought up SQL Injection. I had read some stuff on how LINQ can basically make the common mistakes go away. My boss stated this.
With that said, I do see application for this in the right situation. It should always be through some layer of abstraction though since: - It likely creates a set of generated entities that would need to be regenerated with each subsequent schema change. - The performance usually degrades with a ORM wrapper too. - Proper entity design rarely is the same as database design.I have not heard the part of performance degredation and cannot find information about it. Would experts agree/disagree?New feature! Scroll down to see CP offenders! Current Rant: "My featured CP Idiot of the Day!" http://craptasticnation.blogspot.com/[^]
-
Okay, so I don't know very much about LINQ but our IT head brought up SQL Injection. I had read some stuff on how LINQ can basically make the common mistakes go away. My boss stated this.
With that said, I do see application for this in the right situation. It should always be through some layer of abstraction though since: - It likely creates a set of generated entities that would need to be regenerated with each subsequent schema change. - The performance usually degrades with a ORM wrapper too. - Proper entity design rarely is the same as database design.I have not heard the part of performance degredation and cannot find information about it. Would experts agree/disagree?New feature! Scroll down to see CP offenders! Current Rant: "My featured CP Idiot of the Day!" http://craptasticnation.blogspot.com/[^]
It really depends how you write your Linq. Some of the SQL generated from Linq can be downright convoluted - however, when you know what the issues are and the workrounds are, you can end up with SQL that is every bit as efficient as if you'd handcrafted it. Alternatively (of course) you could always use your stored procedures with Linq.
Deja View - the feeling that you've seen this post before.
-
Okay, so I don't know very much about LINQ but our IT head brought up SQL Injection. I had read some stuff on how LINQ can basically make the common mistakes go away. My boss stated this.
With that said, I do see application for this in the right situation. It should always be through some layer of abstraction though since: - It likely creates a set of generated entities that would need to be regenerated with each subsequent schema change. - The performance usually degrades with a ORM wrapper too. - Proper entity design rarely is the same as database design.I have not heard the part of performance degredation and cannot find information about it. Would experts agree/disagree?New feature! Scroll down to see CP offenders! Current Rant: "My featured CP Idiot of the Day!" http://craptasticnation.blogspot.com/[^]
- The performance usually degrades with a ORM wrapper too. Both true and false: the true part: Ofcourse it will be some overhead to create objects and fill them with data vs just using a raw datareader. Most ORM's have quite a bit of infrastructure overhead, dirty tracking, original values, object status etc etc which will eat both memory and cpu time. If you just have enough time, you can always make specific optimized sql queries for each and every possible usecase in an app and use a datareader and that would perform much better than any ORM. ORM's are also far from the best choise when it comes to batch operations, eg batch deletes or updates. (due to the fact that they need to first load the objects into memory and then send a request to delete / update each of those.. but thats a whole science on its own and different mappers do it differently.) ORM's also perform semi poorly when dealing with aggregations. Linq to Sql however does rather OK here since it supports aggregation functions and projections on DB level. But the batch operation aspect is more of a "dont use the wrong tool" problem. Use ORM:s for what they are supposed to do, and dont use them when it doesnt make sense. The false part: ORM:s can sometimes perform _better_ than stored procs in the real world. Most ORM:s support load spans where you can tell the mapper to only load the fields that you want in a specific usecase. (sadly, Linq to Sql only support loadspans per context, not per query) While if you use stored procs, you most likely have some generic stored procs that reads all customer data or all the order data, just because you are too lazy to write more and because its a PITA to maintain too many sprocs. So in short, the sql generated by a mapper are often more optimized for a specific usecase than your old school sprocs. There is also a slight chance that the people that created the mapper have more knowledge about writing optimized sql queries than you (I said chance) ORM:s in general also support caching in various ways, so sometimes you dont even have to hit the db. -- And even if ORM:s perform worse than handwritten queries, they still perform good enough while they bring shitloads of nice features to the table that your old DAL lib most likely dont have. And if you happen to get performance problems in a specific usecase, there is nothing stopping you from handling that usecase manually.. you will still benefit from the mapper in the other 99% of your app.
-
Okay, so I don't know very much about LINQ but our IT head brought up SQL Injection. I had read some stuff on how LINQ can basically make the common mistakes go away. My boss stated this.
With that said, I do see application for this in the right situation. It should always be through some layer of abstraction though since: - It likely creates a set of generated entities that would need to be regenerated with each subsequent schema change. - The performance usually degrades with a ORM wrapper too. - Proper entity design rarely is the same as database design.I have not heard the part of performance degredation and cannot find information about it. Would experts agree/disagree?New feature! Scroll down to see CP offenders! Current Rant: "My featured CP Idiot of the Day!" http://craptasticnation.blogspot.com/[^]
I'm not going to repeat what others have said, so I'll just add this: It sounds like he is talking about LINQ to Entities (which is only at CTP stage at the moment) rather than LINQ to SQL. LINQ to Entities is the ORM tool that Microsoft are bringing out. It looks quite neat, but I've yet to try it. WRT performance degredation, a good DBA will be able to write more performant stored procedures that match the database than an ORM tool will write SQL Queries. If the database changes the sprocs can be updated and the application need never know. If you change the data model then the application may need to be regenerated (or at least the mapping files need to be redistributed in the case of LINQ to Entities*) With my DBA hat on, I still prefer stored procedures, because then access to and modification of the database is controlled from within the database. Giving away rights to access tables directly is not something I am keen on from a security stand-point. I don't trust developers (even although with a different hat I am one) with my database. Trust is earned and so far the vast majority of developers have been found wanting. Also, take in to account that database security is difficult, and even although you might start out with the best of intentions the number of systems I've seen where a security problem is eventually resolve with the ah-phukkit-lets-just-make-it-dbowner method of sorting out access problems is heart-breaking** So, personally, I'm in turmoil on this. I really like the idea of LINQ to SQL and LINQ to Entities from a developer stand point, but the database administration in me says "You ain't gettin' your dirty paws on my database!" * Again, I've not used it, so this information may be used by the compiler rather than the runtime - I don't know, but many ORM tools use mapping files at runtime. ** No pun intended.
Upcoming FREE developer events: * Developer Day Scotland Recent blog posts: * Introduction to LINQ to XML (Part 1) - (Part 2) My website | Blog