AsQueryable() in Business logic layer - bad practice? (I think so but....)

Question

Say for example I have (pseudo code):

public IEnumerable<User> GetUsers(string name) in my data access layer to Entity Framework, which at the moment does a .ToList() before returning, thus ensuring my business logic layer cannot interfere with my data access layer.

However I need a slightly different variation on this in my business logic layer, for example I need less data (e.g. just userid's or to further filter it).

To have an efficient DB layer I'd want another method returning a subset of the data (overloaded method or whatever).

However, I could "cheat" and omit the ToList(), and my business logic layer tacks on the end an AsQueryable(). Thus my business logic layer is able to manipulate the underlying sql that is created.

What are people's thoughts on AsQueryable() in business logic layers? It seems to me that this is a leaky abstraction over my data access layer, but it could be incredibly convenient, and perhaps because it's in the LINQ namespace (rather than EF namespace), that it's not all that bad to use?

---

EDIT

Something useful to watch out for (and argument against omitting ToList()), is that if code calling it was previously relying on the ToList() for databinding i.e. to avoid the error "Data binding directly to a store query (DbSet, DbQuery, DbSqlQuery) is not supported." You won't get a compile time error, just a runtime error. So you need to make sure ToList() is certainly called before the UI tier.

Answer 1

I would personally just add a second method that does a ToList() in my data access layer and call that. It's neater that way:

functionA()
{
    return myDB.entityA.AsQueryable();
}

functionB()
{
    return functionA().ToList();
}

You're probably going to need to call that same function from somewhere else sometime in the future. Keep it in one place.