1

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

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

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

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

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

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

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

4

2 回答 2

1

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

于 2009-12-18T00:47:55.653 回答
0

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

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

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

于 2009-12-03T04:35:53.747 回答