只读搜索功能。带有 POCO 和 Ef 4.0 的存储过程或 IQueryable

Question

我们有一些搜索功能，可以从数据库返回数以万计的结果，尽管它只会获取需要显示的行，例如前 10 条记录。当请求下一页时，我们再次点击数据库。它根据一组变量搜索我们的数据库，然后可以细化此搜索，这将导致另一个数据库命中。查询相当复杂。

我们一直在寻找适合我们整体架构的不同方法。

第一种方法是使用存储过程，可能会填充实体列表。此存储过程可能很快变得庞大且笨重，但性能会更好。

第二种方法是使用 Linq to Entites 或 Entity SQL 与 Entity Framework 4.0 并在我们的概念层中的代码中创建查询，并通过 IQueryable 填充 POCO 对象。这对我们有以下好处：

• 抽象：我们在应用程序的其他地方使用 EF，因此我们希望 如果在抽象模型上搜索 可能的。
• 类型安全，我们可以在 IQueryable 上链接过滤器，以对象导向的方式干净地做我们想做的事情

我们对这种方法的主要关注是性能。我们希望利用 Parrlel LINQ to Entities 并能够在需要时投入更多硬件。对于更清洁的开发模式来说，小的性能损失是可以的。

我们很高兴听到人们对此的想法和建议......我们对很多这些技术都是新手，所以想听听人们的经验。

Answer 1

我已经进行了一些性能测试，并且在 EF4.0 中使用存储过程填充实体或复杂类型在性能上与通过 ADO.NET 访问的 SP 几乎相同，因此我们将尝试这种方法。使用 EF 的内置查询大约慢了一倍，因此我们将在这种性能关键的情况下使用 SP。

Answer 2

您说最终目标是性能。这对我来说意味着 ADO.NET 和直接的 SQL。在它之上添加 EF 对于不需要状态跟踪、不需要更新能力，甚至不会使用所有结果的东西来说是一个巨大的开销。

针对数据库编写 SQL 并让它尽可能多地进行分页。当您打算扔掉它们时，切勿拉出 1,000 个条目。您也不能利用 EF 的服务器功能来进行 FTS 或索引提示优化等事情。您受制于 EF 运行时，它是通用的，不知道如何利用特定的硬件或服务器。

您还应该查看一些缓存层，您知道用户将在一定百分比的时间内查询下一组。获得 2 倍的初始结果并在他们回调时缓存后半部分会更便宜。否则，您会在某个时候使它们过期。