linq vs Store-procedure [英] linq vs Store-procedure
问题描述
我打算学习linq，但我想要明确怀疑/混淆......来自Linq和3层架构的
（我现在正在使用这个）哪一个真实的好时间申请，任何特殊原因选择linq？
想知道，
比较Linq和storeprocedure对于不同的点...
性能，
速度，
数据锁定，
transaction -rollback -commit一组查询
sql-injection，
维护
等
这不是功课。我需要建议清除我的怀疑:)
所以，如果你对这两方面都有所了解，那么请建议我哪个好。如果使用linq会更有益吗？
I am planning to learn linq but I want a clear doubt/confusion about...
from Linq and 3-tier architecture(I am using this one now) which one is good in real time application, any special reasons to choose linq?
want to know,
comparision of Linq and storeprocedure for different points like...
performance,
speed,
data locking,
transaction -rollback-commit set of queries
sql-injection,
maintenance
etc.
It''s not homework. I need suggestions that clear my doubts :)
so, If you have knowledge for both then please kindly suggest me which is good one. should it will be more beneficial to work with linq?
推荐答案
我们不做你的功课：这是有原因的。它就是为了让你思考你被告知的事情，并试着理解它。它也在那里，以便您的导师可以识别您身体虚弱的区域，并将更多的注意力集中在补救措施上。
亲自尝试，你可能会发现它不是你想的很难！
We do not do your homework: it is set for a reason. It is there so that you think about what you have been told, and try to understand it. It is also there so that your tutor can identify areas where you are weak, and focus more attention on remedial action.
Try it yourself, you may find it is not as difficult as you think!
参考下面的链接..
希望它对你有所帮助。
性能比较LINQ to SQL / ADO / C＃ [ ^ ]
并参考以下内容：
refer below links..
Hope it will helpful for you.
Performance Comparisons LINQ to SQL / ADO / C#[^]
and refer below :
LINQ优于sprocs的一些优点：
类型安全：我想大家都明白这一点。
抽象： LINQ-to-Entities尤其如此。这种抽象还允许框架添加您可以轻松利用的其他改进。 PLINQ是向LINQ添加多线程支持的示例。添加此支持的代码更改很少。执行简单调用sprocs的数据访问代码会更加困难。
调试支持：我可以使用任何.NET调试器来调试查询。使用sprocs，您无法轻松调试SQL，并且该体验主要与您的数据库供应商有关（MS SQL Server提供了查询分析器，但通常这还不够）。
供应商不可知： LINQ适用于大量数据库，支持的数据库数量只会增加。 Sprocs并不总是可以在数据库之间移植，因为它们具有不同的语法或功能支持（如果数据库支持sprocs）。
部署：其他人已经提到了这一点，但是部署单个程序集比部署一组sprocs更容易。这也与＃4相关。
更容易：您不必学习T-SQL来进行数据访问，也不必学习数据访问调用sprocs所需的API（例如ADO.NET）。这与＃3和＃4有关。
LINQ与sprocs的一些缺点：
网络流量： sprocs只需要通过线路序列化sproc-name和参数数据，而LINQ发送整个查询。如果查询非常复杂，这可能会非常糟糕。但是，LINQ的抽象允许微软随着时间的推移改进这一点。
不太灵活： Sprocs可以充分利用数据库的功能集。 LINQ在它的支持下往往更通用。这在任何类型的语言抽象中都很常见（例如C＃与汇编程序）。
重新编译：如果需要更改数据访问的方式，则需要重新编译，版本并重新部署您的程序集。 Sprocs有时可以让DBA调整数据访问例程而无需重新部署任何东西。
安全性和可管理性也是人们争论的事情。
安全性：例如，您可以通过直接限制对表的访问来保护敏感数据，并将ACL放在sprocs上。但是，使用LINQ，您仍然可以限制对表的直接访问，而是将ACL放在可更新的表视图上以实现类似的结束（假设您的数据库支持可更新的视图）。
可管理性：使用视图还可以使您的应用程序不受模式更改（如表规范化）的影响。您可以更新视图，而无需更改数据访问代码。
Some advantages of LINQ over sprocs:
Type safety: I think we all understand this.
Abstraction: This is especially true with LINQ-to-Entities. This abstraction also allows the framework to add additional improvements that you can easily take advantage of. PLINQ is an example of adding multi-threading support to LINQ. Code changes are minimal to add this support. It would be MUCH harder to do this data access code that simply calls sprocs.
Debugging support: I can use any .NET debugger to debug the queries. With sprocs, you cannot easily debug the SQL and that experience is largely tied to your database vendor (MS SQL Server provides a query analyzer, but often that isn''t enough).
Vendor agnostic: LINQ works with lots of databases and the number of supported databases will only increase. Sprocs are not always portable between databases, either because of varying syntax or feature support (if the database supports sprocs at all).
Deployment: Others have mentioned this already, but it''s easier to deploy a single assembly than to deploy a set of sprocs. This also ties in with #4.
Easier: You don''t have to learn T-SQL to do data access, nor do you have to learn the data access API (e.g. ADO.NET) necessary for calling the sprocs. This is related to #3 and #4.
Some disadvantages of LINQ vs sprocs:
Network traffic: sprocs need only serialize sproc-name and argument data over the wire while LINQ sends the entire query. This can get really bad if the queries are very complex. However, LINQ''s abstraction allows Microsoft to improve this over time.
Less flexible: Sprocs can take full advantage of a database''s featureset. LINQ tends to be more generic in it''s support. This is common in any kind of language abstraction (e.g. C# vs assembler).
Recompiling: If you need to make changes to the way you do data access, you need to recompile, version, and redeploy your assembly. Sprocs can sometimes allow a DBA to tune the data access routine without a need to redeploy anything.
Security and manageability are something that people argue about too.
Security: For example, you can protect your sensitive data by restricting access to the tables directly, and put ACLs on the sprocs. With LINQ, however, you can still restrict direct access to tables and instead put ACLs on updatable table views to achieve a similar end (assuming your database supports updatable views).
Manageability: Using views also gives you the advantage of shielding your application non-breaking from schema changes (like table normalization). You can update the view without requiring your data access code to change.
查看类似的讨论：
LINQ与StoredProcedure [ ^ ]
LINQ与StoredProcedure [ ^ ]
存储过程与LINQ [ ^ ]
存储过程与LINQ [ ^ ]
另外看看这篇文章
使用编译的查询加速Linq到Sql [ ^ ]
Check out similar discussion:
LINQ Vs StoredProcedure[^]
LINQ Vs StoredProcedure[^]
Stored Procedures vs LINQ[^]
Stored Procedures vs LINQ[^]
Also have a look on this article
Speed up Linq to Sql with compiled queries[^]
这篇关于linq vs Store-procedure的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
