传递一个未执行的IEnumerable作为参数不好的做法?

时间:2011-09-22 18:30:41

标签: linq-to-entities entity-framework-4.1

查看我们的一些业务逻辑代码,我发现某些方法正在传递未执行的IEnumerables作为参数,例如:

GetDetails(IEnumerable <Entity> item) { // do something with the item }

现在代码工作正常,但是我在调​​试时看到的是参数传递原始查询,而不是任何东西的集合。对我来说,这似乎有点不对,因为如果查询指向数据库,每次使用此IEnumberable时,您可能会访问数据库。

所以我要问的是,将未执行的IEnumerable作为参数传递给方法不良做法?

经过更多调查

我已经在stackoverflow上阅读了更多内容,并找到了this particular question Eric Lippert所说的内容:

  

请记住,查询表达式为您提供了一个表示查询本身的对象。该对象不表示查询的结果,该对象表示查询。可以把它想象成一个SQL查询字符串,只是更聪明。您询问查询结果,并执行查询。你再次问它,再次执行查询;不能保证第二次问你的结果是一样的;从那时起世界可能已发生变化

对我来说,这似乎是说如果你要使用诸如IEnumberable之类的延迟查询,在使用它时要小心,当你使用时,你可能得不到预期的结果。但进一步的答案我发现Bevan说他亲自这样做:

  

方法的参数 - 使用IEnumerable,除非需要更具体的接口。

所以我的问题仍然存在,是将未执行的IEnumerable作为参数传递给方法不良做法,或者我不应该关心请求数据的时间,只是请求它。

1 个答案:

答案 0 :(得分:1)

一旦数据离开业务逻辑层,它应该是一个不再连接到数据库的硬集合。在业务逻辑中的方法之间传递集合应该没问题,因为您可能希望在不从数据库中加载整个数据集的情况下为查询添加条件/过滤。