I'm new to the entity framework. Some screen casts I've been watching, show results sets being held in memory with their changes. This seems like it could use a lot of memory.
Does this mean that EF isn't suitable for ASP.NET development? Does the entity framework have a memory efficient pattern similar to the SqlDataReader?
It looks like it that if you enumerate through the query result as objects, a DbDataReader is actually used and objects are created on the fly, so only 1 row will be in memory as an actual EntityObject. You can also access the data at a DataReader level using it's EntityClient Provider, but if you're concerned about optimal performance, I suppose you should stick to plain ADO.NET.
I've used Entity Framework without memory or performance problems on reasonably high traffic sites (12,000 - 20,000 unique visitors per day with 250k pageviews).
Also, you may want to wait for Entity Framework 4.0, or use the pre-release. It has lots of improvements, one of which is support for POCO (Plain Old CLR Objects).
"Does the entity framework have a memory efficient pattern similar to the SqlDataReader?"
No, the EF makes complete copies of objects in RAM similar to a DataSet and DataRelations, etc, but it keeps them in objects instead. It then also has to keep copies of each of the objects changes (Changesets). Each of those changes are then build up as SQL to update the database if you submit the changes back.
SqlDataReader is a forward only lightweight reader to grab a single row at a time. EF is loading all your answers to the queries into object collections with change tracking on top of it.
Is it suitable for your app? I don't know. If you need fast as possible and smallest amount of RAM then ADO.NET is the only way to go. Any abstraction placed on top of ADO.NET is going to add overhead, memory etc.
EF will use more memory than using ADO.net directly (assuming that you use ADO.net correctly)
Having said that, we have used EF on large ASP.net projects with no memory problems.
The only situation I can think of is if you are handling large binary objects, and you want to stream them instead of loading them into memory.