我不得不为我的大学开发系统，其中包括跟踪几乎所有的数据（讲座，讲师，助教，学生等）。 我的数据库有30张桌子，它很漂亮复杂。 我用EF和linq来解决连接数据库并从中查询。 但是我越走越多，我的查询变得越来越难写，更不用说维护。 以下是一个查询的示例：http://pastebin.com/Za1cYMPaLinq，实体框架及其用法
这是非常混乱，你可以看到。
那么，我滥用LINQ（LINQ可以解决这个问题，但以不同的方式）或LINQ只是不是像这样的更复杂的系统？
这是一般性问题，不是解决特定问题的方法之一。
一般来说，通过将您的重复代码抽象为可重复使用，易于维护的组件可以减少复杂性。
你的具体情况，可以通过实施Repository和Specification模式使你的代码更一致，更易于阅读，并且易于维护可以降低复杂性。
Huy Nhuyen提供了非常有用的一系列文章，解释了存储库模式，规范模式以及如何将它们与实体框架有效结合以获得更好的代码。这些都可以在：
如果用原生SQL编写，您认为查询会更好还是更易于维护？在这种情况下，您可以隐藏存储过程中的查询。一旦你进入高级查询，它总是混乱。通过将子查询隐藏到数据库视图或EF查询视图中，可以减少一些复杂性。但是，如果您已经高度规范化了OLTP数据库，并且您需要执行复杂的报告/分析/数据挖掘查询，那么它总是会很大且难以维护。这就是为什么OLAP系统存在的原因（我没有检查你的查询的内容 - 只是长度，所以不要把它作为构建OLAP Cube的原因）。
更重要的是查询的性能...
我想问问你关于LINQ综合性能。 linq比一些原生sql慢多少？ – Vajda 2011-06-06 20:08:20
@Vajda，一些性能测试的结果发布在[本博客文章]（http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html） – smartcaveman 2011-06-06 20:13:05
@smartcaveman Woow，linq to sql对于linq到实体的差异并不是很慢。 – Vajda 2011-06-06 20:18:35
Ooof，这是非常讨厌的。
你应该考虑一下你的数据库设计。我相信拥有如此多的表格会导致您的查询过于复杂。我放置好的一组视图（或存储过程）可以简化查询逻辑。但是这不会简化整个系统，因为在某些时候你必须连接所有这些表。
-1，是的，它很丑。但绝对不需要使用存储过程。 OP的问题是过度的复杂性和维护难度。从长远来看，增加应用程序的最小可维护部分的复杂性并不会对此有所帮助。有一个更好的方法。我没有使用视图的问题。 – smartcaveman 2011-06-06 20:11:50
@smartcaveman实际上很适合你使用存储过程。不一定隐藏复杂性，但保护性能。这现在已经很丑陋了，但看看它在SQL profiler中生成的内容然后分析该查询 – BritishDeveloper 2011-06-06 20:38:32
@smartcaveman您注意到您对Stored Procedures的攻击。但是，您认为SQL层最不可维护的假设仅仅是一种意见，仅此而已。一个复杂的系统是一个复杂的系统。在不改变业务需求的情况下，您可以做的任何事情都可以改变这一点 – Jeff 2011-06-06 21:01:18
不知道我在这里遵循你的逻辑。我认为复杂性来自数据库设计。将这些查询中的一部分移入视图（或存储过程）可以帮助简化存储库层。另外，我不确定我是否同意你的假设，即使用Repository和Specification模式可以降低复杂性并提高可维护性。如果有的话，它会将这些担忧转移到架构的不同层面。 – Jeff 2011-06-06 20:56:56
@Jeff，如果他的老板决定将数据库移动到Oracle或文档数据库，会发生什么？然后，所有内容都需要重新编码，因为业务逻辑已被移至SQL数据库，该数据库特定于该特定实施。你是正确的，因为它把问题转移到了不同的层次，但是由于OP讨论LINQ，我不得不假定他是一个交易程序员，而不是数据库管理员（是的，这些常常是重叠的，但并不总是）。在这种情况下，似乎维护代码比数据库更容易。 – smartcaveman 2011-06-06 20:59:20
那个论点是完整的b.s.除非你为一家软件公司工作。我一直存在很长时间才知道决策并非如此。让自己远离未来可能发生或可能不会发生的事情，只会增加复杂性。 – Jeff 2011-06-06 21:03:05