Depending on the purpose the data is needed for, the developer may set different priorities on the way they are loaded.

Generally, this is the speed - the faster database operations are, the more reliably and user-friendly the application becomes, and the less resources it consumes. The simplest way to get the higher speed of fetching is to limit the result set in some way - for example, by loading only a subset of columns for each row, or by filtering the rows themselves. And if eventually you do have to get the filtered data back, there should be a way to do so. With the filtered entities, it is quite easy, since you can just perform a query with some other criteria. With columns, the problem is that a loaded entity is materialized and cached, so querying again will only return the same object. Thus, the entity object per se should implement this mechanism. Fetching a limited set of entity fields is discussed in details in the Lazy Loading topic.

Getting back to limiting entity sets, there are situations when the same filter should be applied multiple times to different entity collections. For example, these collections may be dependent ('child') objects of different 'parent' entities. Re-defining the same query for each new collection is at least tedious, so LinqConnect provides a way to set the filter criterion once for all objects of the 'parent' type. See the Filtering Related Entities topic for more information.

In certain situations the speed may be not so important compared to the necessity of loading the full entity graph. The general description of such a situation is that this graph should be passed to a disconnected (from the database) part of the application, where loading new data batches when the need arises is not an option. The particular cases may be web services, layered applications and so on. In such cases, getting as little data as necessary should be replaced with grabbing everything that may eventually come in handy. The Eager Loading topic is dedicated to this approach.