title: Is there any way to create a LINQ query as a variable without having the data source (yet)?
body: <p><strong>Preamble:</strong><br>
  My core question is very similar to this one: <a href="https://stackoverflow.com/questions/1030992/how-can-i-write-a-clean-repository-without-exposing-iqueryable-to-the-rest-of-my">How can I write a clean Repository without exposing IQueryable to the rest of my application?</a> which has remained unanswered. I am hoping that if I approach the problem in a different way, and ask a slightly different question, I may get a result. I will repeat some of the content from this other question to avoid requiring readers to read it for context.</p>
  
  <p><strong>Problem:</strong><br>
  I'm working with POCO entities, and Entity Framework 4. I am trying to allow for sophisticated ad-hoc filtering of entity sets at the application layer, while simultaneously trying to avoid exposing <code>IQueryable&lt;T&gt;</code> past my repository boundary. This is leaving me with some complications.</p>
  
  <ul>
  <li><p>I do not want to create a single massive filter method on the repository that takes a huge list of parameters, such as: </p>
  
  <pre><code>IEnumerable GetFilteredCustomers(string nameFilter, string addressFilter, bool isActive, int customerId, ...)
  </code></pre>
  
  <p>Not only is this extremely cumbersome to use, but it's super ugly to look at, especially if it's mostly a bunch of nulls, etc. It's also not as maintainable as I would like.</p></li>
  <li><p>I do not want to create a huge set of filter methods on the repository, such as:</p>
  
  <pre><code>IEnumerable GetActiveCustomers()
  IEnumerable GetCustomersByName()
  </code></pre>
  
  <p>There are a number of problems with this approach, including needing a huge list of methods which grows to <code>n!</code> where n is the number of available filter conditions if I want to be able to combine them in arbitrary ways. (i.e. all active customers with name George). Also highly difficult to maintain.
  <br></p></li>
  <li><p>I do not want to create chainable methods (Fluent Interface) that manipulate <code>IEnumerable&lt;T&gt;</code>, because ultimately that involves bringing back a huge result set from the database and filtering it down in-memory which is not a scalable solution.</p></li>
  <li><p>I can't create a Fluent Interface that manipulates <code>IQueryable&lt;T&gt;</code> because as I've already said, I don't want to expose the <code>IQueryable&lt;T&gt;</code> past the repositories.</p></li>
  <li><p>I'd like to avoid simply rehashing the single massive filter method by passing in an object full of parameters instead of a large parameter list, although at this point this might be the least ugly solution.</p></li>
  </ul>
  
  <p><strong>Ideas:</strong><br>
  Ultimately, I think an ideal solution would be discovering some way to create a full query that doesn't know the source, and store it as a parameter. I could then pass that into the repository, where the source is known, and apply the query to the source and return the results.</p>
  
  <p>To clarify; in contrast to simply creating an object of parameters as mentioned above, I'd like to use the raw LINQ queries, but store them in a variable somehow, and apply them to a data source later. I suspect the return type would have to be known ahead of time, but I'm perfectly fine with defining that and having it known in advance.</p>
  
  <p>To view it from yet another perspective, consider the following:</p>
  
  <pre><code>IQueryable&lt;Customer&gt; filteredCustomers = customerRepository.GetAll()
      .Where(c =&gt; c.FirstName == "Dave")
      .Where(c =&gt; c.IsActive == true)
      .Where(c =&gt; c.HasAddress == true)
      ;
  </code></pre>
  
  <p>I want to package up the three Where clauses as a query object, completely separate from the customerRepository.GetAll(), pass it around as a parameter and apply it later.</p>