人们为什么要使用linq to sql? [英] Why do people use linq to sql?

问题描述

给出前提:

• 有胜任的sql程序员 (相关-编写sql查询不是问题)
• 有胜任的应用程序开发人员 (相关的-有简单/强大/灵活的体系结构可以处理代码中的连接和简单查询)

• There are competent sql programmers (correlary - writing sql queries are not an issue)
• There are competent application developers (correlary - there is simple/strong/flexible architecture for handling connections and simple queries from code)

人们为什么要使用linq来进行SQL?

Why do people use linq to sql?

• 每笔交易都有额外的开销
• 对于中等复杂度的计算，很可能会降低性能(数据库是为处理集和计算而建立的，并且有工程师团队进行了优化-为什么要搞混呢?)
• 灵活性丧失(如果要添加另一个ui(非.NET应用程序)或访问方法，则必须将查询放回数据库或创建单独的数据访问层)
• 由于没有对db上的写入/更新/读取进行集中控制而导致安全性下降(例如，一条记录已更改-如果您允许应用程序使用linq to sql进行更新，那么您将无法证明哪个应用程序已更改它或应用程序的哪个实例对其进行了更改)

我不断看到有关linq to sql的问题，并且想知道我是否缺少某些内容.

I keep seeing questions about linq to sql and am wondering if I'm missing something.

推荐答案

我不断看到有关linq to sql的问题，并且想知道我是否缺少某些内容.

I keep seeing questions about linq to sql and am wondering if I'm missing something.

这并不是您缺少什么.这是您拥有大多数商店所没有的东西:

It's not that you're missing something. It's that you have something most shops don't have:

有胜任的sql程序员

There are competent sql programmers

此外，在您的商店中，那些精干的sql程序员更喜欢编写sql.

Additionally, in your shop those competent sql programmers prefer to write sql.

以下是逐点回答:

每笔交易都有开销

There is overhead added to each transaction

通常是正确的.对于许多(但不是全部！)方案，在需要使用CompiledQuery运行它们之前，请先翻译查询，以免发生这种情况.

Generally true. This can be avoided by translating the queries before they are needed to run using CompiledQuery for many (but not all!) scenarios.

中度复杂的计算很可能会降低性能(数据库用于处理集和计算，并且有工程师团队进行优化-为什么要搞混呢?)

There is strong likelihood of performance loss for moderate-complex calculations (DBs are made for processing sets and calculations and had teams of engineers working out optimization - why mess with this?)

要么您正在编写linq(将其翻译为sql)，然后从优化器生成计划，要么是您在编写sql，然后由优化器生成计划.在这两种情况下，您都在告诉机器您想要什么，并且应该弄清楚如何做.您是否建议通过使用查询提示来破坏优化器是一个好习惯?许多称职的SQL程序员会不同意该建议.

Either you're writing linq, which is translated to sql, and then a plan is generated from the optimizer - or your writing sql from which a plan is generated by the optimizer. In both cases you are telling the machine what you want and it is supposed to figure out how to do it. Are you suggesting that subverting the optimizer by using query hints is a good practice? Many competent sql programmers will disagree with that suggestion.

灵活性丧失(如果要添加另一个ui(非.NET应用程序)或访问方法，则必须将查询放回数据库或创建单独的数据访问层)

There is loss of flexibility (if you want to add another ui (non .NET app) or access method, you either have to put the queries back in the db or make a separate data access layer)

许多使用linq的人已经是SOA. linq生活在服务中.非.NET应用程序将调用该服务. Bada-bing bada-boom.

A lot of people using linq are already SOA. The linq lives in a service. The non .NET app calls the service. Bada-bing bada-boom.

由于没有对db上的写入/更新/读取进行集中控制而导致安全性下降(例如，一条记录已更改-如果您允许应用程序使用linq to sql进行更新，那么您将无法证明哪个应用程序已更改或应用程序的哪个实例对其进行了更改)

There is loss of security by not having a centralized control of write/update/read on db (for example, a record has changed - if you allow applications to use linq to sql to update, then you cannot prove which application changed it or what instance of an application changed it)

这根本不是事实.您可以证明连接了哪个应用程序并发出sql命令，也可以证明您连接了哪个应用程序并调用了sproc.

This is simply not true. You prove which application is connected and issuing sql commands the same way you prove which application is connected and calling a sproc.

这篇关于人们为什么要使用linq to sql?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！