EF is designed to easily get entities from the data store. The entities can get passed around inside the application, but you may have different entities acting against the same data source. For example, on a customer screen you may have all kinds of info in the CustomerEntity such as email address, credit limit, account balance, etc. But a shipping function wouldn't need all that and have a different CustomerEntity. (They would, of course, be named differently.) My cursory read of Rick's article says he wants to avoid having two Customer entities for this and just have one, then use LINQ to get the subset of data needed. I think that's where you were heading in your original post. And you ran into LINQ problems Rick was talking about.

I haven't dug much into LINQ and not at all into EF. But I understand the concepts of both. I've been too busy working on my book for the past few months. But, I do see a light at the end of the tunnel on that.

>So EF is not really designed for N tier data access? Or maybe the problem is LINQ? What technology would you suggest? I thought this link was interesting.
>
>http://west-wind.com/WebLog/posts/33570.aspx