应该使用Linq还是Not？

Question

我正在设计我的项目架构。 在我们的团队辩论中是否使用Linq或不使用。

我在Google上浏览linq我发现这个link，它给出了linq的简要优点和缺点。

从我们的项目角度来看，有三个关键点。

1. DBML并发问题
2. 小型数据集构建查询所需的时间比执行
要长
3. 加入很慢

谈论Linq to Entities。根据我的项目要求，所有这些都是Linq相关的问题，因为我的项目很大。 所以性能是非常重要的关键因素。

我们可以解决这些linq问题吗？如果是的话，如何解决？

Answer 1

我通读了那篇文章中的一些回复，我不得不同意并不同意其中的很多回复。我发现使用linq在开发时间快速转换的最重要因素。 SQL查询中没有更多的拼写错误。不浪费时间创建复杂的SQL查询。 linq与实体和linq与sql的区别也不同。你没有考虑到这一点。我建议你仔细阅读。提示：转向linq到实体。

回答你的问题。

1. 我没有将并发问题与linq（与实体）联系起来。这就是你实现它的方式。如果您需要（批量）更新的原始速度，您可以始终使用ADO.NET。

2. 如果您仔细地构建了linq查询，则只需提取所需的数据。如果您担心linq在构建查询时遇到性能损失，您可以创建已编译的linq查询。

3. 如果你创建了一个合适的模型，其中所有的关系都不会很慢。

Answer 2

与往常一样，这个问题的答案取决于它。这几天的方向肯定是pro-ORM。虽然你肯定对存储过程或直接sql命令更好地控制性能和原子记录更新，但根据我的个人经验，这些好处超过了维护/更新模式和过程所花费的时间。对于敏捷团队来说，这可能是一个很大的缓慢。使用强类型ORM工具（如Entity Framework或N-Hibernate）的另一个主要好处是可以防止代码与数据库架构和存储过程产生很大分歧。这可能会导致一些非常大的问题。

一般情况下，我会在使用ORM工具时出错，然后在必要时使用存储过程。

要回答您的具体问题，请使用Entity Framework作为具体示例：

1. 实体框架4有一些工具可以帮助处理OptimisticConcurrencyExceptions。您可以尝试自己解决它或将异常抛到堆栈中。
2. 这可能是微观优化。通常，实体框架非常快。在你遇到障碍之前，你更有可能处理I / O问题。
3. 如果您使用数据库或延迟加载进行大量的往返操作，则联接可能会很慢。实体框架还支持eager-loading，以便一切都可以在一个查询中完成。

最终，如果归结为它，您可以随时使用存储过程。当我有很多需要独占行锁的并发操作时，我这样做。

我在EntityFramework中看到的一个缺点是，有时会遇到与Postgres一起使用的问题，但是有非Visual Studio工具可以提供帮助。