Question

I’m working through the ‘Data Binding’ chapter in Pro WPF in C# 2008.

They have you set up this class:

public class StoreDB {     public Contact GetContact(int id) {...}     public List<Contact> GetContacts() {...} } 

The idea is to call these methods, getting either a Contact or a List<Contact> and bind these to the appropriate controls using LINQ on the latter method to filter/sort your objects.

This all makes sense.

However, what happens when you have 100,000 contacts and you want to get 3 of them? Your GetContacts() method gets 100,000 and your LINQ picks out three of them?

Isn’t this super inefficient?

How are real-world applications built to avoid this?

Answer 1

Welcome in the Linq world!

You want to return an IQueryable<Contact>:

public class StoreDB {     public Contact GetContact(int id) {...}      // change to this:     public IQueryable<Contact> GetContacts() {...} } 

Now you can say this without wasting cycles or bandwidth:

IQueryable<Contact> SerachByFirstName(StoreDB store, string searchParam, int limit)  {     return store.GetContacts()         .Where(c => c.FirstName == searchParam)         .Take(limit); } 

In fact, this still won’t dispatch a query to the database unless you start enumarting over the IQueryable. That is, you still can add more Where() or OrderBy() or what ever and they will be merged and sent to the source together when the query is finally evaluated.

---

Of course this doesn’t help you to bind to the UI. But that is a hard problem. You either have to expose the underlying EntitySet to WPF or use a MVVM (or similar) architecture to separate data access and UI.