Is there any overhead with LINQ or the Entity Framework when getting large columns as part of an entity?

Question

Let's say you have a table containing articles and you want want to display a list of them, excluding the actual article text. When you get a list of the article objects using LINQ or the Entity Framework, is there a LOT of overhead associated with getting that text column too? I assume that when you start enumerating the list, the article text will be stored in memory until the objects are disposed of.

So would it make sense to create an intermediary object that doesn't contain the text column? If so, how would you do this? Make a class inside your DAL, allow the ORM to automatically create one by setting up a stored procedure, or some other process?

Answer 1

The overhead isn't huge (just the cost of sending the data over the wire), but if you don't need the data sure, don't return it. I find the easiest way is to use anonymous types:

from a in Context.Articles
select new {Name = a.Name, Author = a.Author};

Since you're not actually materializing any Article instances, the Entity Framework won't need to fill out all the properties of an instance.

Answer 2

If you don't need the data you should definitely create a different type. By convention I typically name this sort of class "nnnInfo" or "nnnListItem". To create ArticleListItem, in L2S, simply drag the table to your DataContext designer a second time. Then rename it from 'Article1' to 'ArticleListItem' and remove the unneeded properties (rt click, delete). In EF, the process would be similar. As Craig notes, you could use anonymous types, but by creating a concrete type, you can reuse throughout your app, expose via services, etc.

A second way to do this would be to create the class manually and write an extension method to return ArticleListItem:

public static IQueryable<ArticleListItem> ToListItems(this IQueryable<Article> articles)
{
 return from a in articles select new ArticleListItem{ Title = a.Title, ...}
}

This would allow you to "cast" any queries against Article as ArticleListItem...