为什么人们使用linq来sql？

Question

鉴于前提:

• 有称职的SQL程序员(相关 - 编写SQL查询不是问题)
• 有称职的应用程序开发人员(相关 - 有简单/强大/灵活的架构,用于处理连接和代码中的简单查询)

为什么人们使用linq来sql？

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

我一直看到关于linq到sql的问题,我想知道我是否遗漏了一些东西.

Answer 1

我一直看到关于linq到sql的问题,我想知道我是否遗漏了一些东西.

这不是你错过了什么.这是你有大多数商店没有的东西:

有称职的SQL程序员

另外,在你的商店,那些称职的sql程序员更喜欢编写sql.

这是一个逐点响应:

每笔交易都增加了开销

一般都是.这可以通过在需要使用CompiledQuery许多(但不是全部!)场景运行之前转换查询来避免.

对于中等复杂的计算,很可能会出现性能损失(数据库用于处理集和计算,并且有工程师团队正在进行优化 - 为什么要搞这个？)

要么你正在写linq,它被翻译成sql,然后从优化器生成一个计划 - 或者你的编写sql,优化器生成一个计划.在这两种情况下,你都在告诉机器你想要什么,它应该弄清楚如何去做.您是否建议使用查询提示破坏优化程序是一种好习惯？许多称职的sql程序员不同意这个建议.

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

很多使用linq的人已经是SOA了.linq住在一项服务中.非.NET应用程序调用该服务.Bada-bing bada-boom.

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

这是不正确的.您可以证明哪个应用程序已连接并发出sql命令,就像您证明哪个应用程序已连接并调用sproc一样.

Answer 2

让我列举几点:

1. 有些小型软件公司或中型公司在内部开发软件,他们可能更关注获得许多应用程序开发人员,而不是获得自由职业者数据库开发人员,甚至永久雇用他们.
2. 在大多数情况下,由于要处理的数据量或由于流量低,开销不是问题.此外,正确使用时,LINQ to SQL的执行速度与大多数SQL查询+相关的.net代码一样快.
3. 许多公司只是坚持使用Microsoft堆栈,他们只能享受集成.其他一些公司使用SOA开发并没有问题.其他人不会被迫选择LINQ-to-SQL,如果他们做出选择就是如何整合它的问题.没有人说LINQ-to-SQL是一个银弹:)
4. 我相信使用LINQ-to-SQL 可以获得安全性,因为我遇到了许多SQL查询,它们使用字符串连接等非转义数据,并且解释整个参数化查询的想法从未如此简单.此外,由于所有查询最终都会转换为SQL,除非您描述的跟踪问题是通过存储过程发生的,否则完全没有任何问题.

我也相信你的问题可以更广泛地提出来解决所有ORM而不仅仅是LINQ-to-SQL,而且我所说的大部分内容都适用.

Answer 3

问题是,某个地方很难有一个有能力的SQL开发人员喜欢编写SQL而不愿意做其他事情.我认为自己在SQL方面很有能力,我以前用存储过程或参数化查询做我所有的数据访问层.麻烦的是它需要很长时间而且很无聊.我宁愿编写出色的应用程序,而不是搞乱数据访问层,这些层基本上有一个select,insert,update和delete SQL语句(或proc),每个数据对象重复几十次.

Linq-to-SQL消除了一些重复性.它有一个从数据库模式自动生成业务对象的工具,它为您提供了一个很好的集成查询语言,它是经过验证的编译时类型,并且在您的代码中(存储过程很难控制源代码控制)

我可以在Linq-to-sql中编写DAL的速度比使用普通SQL,存储过程或参数化查询快几倍.

如果你想保持使用存储过程,linq-to-sql和EF都支持使用存储过程进行所有数据访问,你只需要设置适当的映射.因此,如果需要,您仍然可以使用存储过程来记录详细信息并实现安全性.我们倾向于选择使用Windows身份验证,并使用它来限制对各个用户的每个表的访问,然后我们在表上有一堆触发器来跟踪详细信息以进行审计.

我将很快注意到的两件事是,首先,实体框架似乎得到了MS的更多支持,我怀疑这将被认为是未来的默认标准,而不是linq-to-sql.其次,在.Net 3.5中,EF和linq-to-sql对n层断开连接的应用程序没有很好的支持.在这两种方法中,您都需要在断开连接的层中序列化数据上下文,或者手动分离并重新附加数据对象.这在.net 4.0中有很大的改进.根据您可以使用的版本,可以考虑一些事项.

Answer 4

以同样的方式/精神存在的问题/答案:

• Linq to SQL是不是错过了这一点？ORM-mappers(SubSonic等)不是次优解决方案吗？
• LINQ-to-SQL vs存储过程？
• Linq对SQL有什么问题？
• 当我有LINQ to SQL时,为什么需要存储过程
• 如果使用LINQ to SQL,还有什么理由学习SQL查询/语法吗？
• /sf/ask/15159861/

我个人认为没有正确或错误的答案.这取决于你正在开发什么以及你如何开发它.如果你需要锐利的性能,有一个过于复杂的数据模型等...跳过抽象.如果您觉得抽象可以加快您的开发时间,就像在单个代码库中捕获所有应用程序逻辑一样......使用它.

Answer 5

对我来说，将 linq 写入 sql 代码比编​​写一堆存储过程花费的时间少得多。当设计尚未完成时尤其如此，在这种情况下，我还不知道我想在 C# 对象上做多少工作，以及我想在 SQL 中做多少工作。

所以，我可以跳过构建数据集，我不必单击 click click 添加查询，基本上，linq to sql 意味着我可以在更短的时间内更改我的代码。

此外，作为 Haskell 的忠实粉丝，我可以使用 linq to sql 编写大量函数式代码，并且它可以正常工作。