Devolución Enumerable.Empty <T>() .AsQueryable() ¿una mala idea?

Question

Esto se explica probablemente con algo de código:

public IQueryable<DatabaseRecord> GetQueryableLinkedRecords() 
{ 
    if(this.currentlyHeldIds.Count() == 0) 
    { 
     return Enumerable.Empty<DatabaseRecord>().AsQueryable(); 
    } 
    else 
    { 
     return from r in this.DBContext.DatabaseRecords 
       where this.currentlyHeldIds.Contains(r.Id) 
       select r; 
    } 
} 

La idea es que no hay razón para consultar hecho el PP de nuevo si no hay de currentlyHeldId para consultar sucesivamente. LINQ to SQL aún consultará el db si actualmenteHeldIds no tiene valores. ¿Hay algo malo con este enfoque? Me doy cuenta de que hay otras preocupaciones relacionadas con el retorno de IQueryable en general, pero dejando esos argumentos de lado, ¿hay algo de malo en tratar de eludir la llamada a db de esta manera?

Answer 1

Creo que debería reconsiderar lo que su función realmente va a hacer. Si devuelve un IQueryable<T>, la consecuencia es que las personas que llaman almacenarán la consulta resultante y recibirán resultados actualizados cuando realmente ejecuten la consulta. Recuerde: la base de datos no se consultará en este caso hasta que se invoque .ToList(), .ToArray(), foreach, etc. en la consulta.

Si su objetivo, sin embargo, es devolver el estado actual de la consulta, entonces su método debería simplemente devolver un IList<T> o algo similar. A continuación, puede devolver un List<T> vacío, o llamar al .ToList() en la consulta que de lo contrario construye y devolverlo.

En general, trataría de evitar devolver consultas vacías, ya que puede confundir a las personas que llaman sobre lo que realmente están obteniendo.

Answer 2

Me parece bien. Si la funcionalidad es idéntica desde el lado consumidor, debería ser perfectamente buena.