title: Should "DbContext" and "DbSet" be exposed for a pure POCO application
body: <p>Can someone enlighten me about the intended (best-practice) use of "DbContext" and "DbSet" where data consumers should have no dependency on the EF whatsoever (100% POCO). While all the examples I find explain how to create POCO classes for the underlying data source (corresponding to RDBMS tables usually), they still expose "DbContext" and "DbSet" to the outside world (including MSFT's own examples on how to do data binding with these classes). This seems to defeat or (seriously) water down the benefits of using POCO. IOW, clients are still bound to the EF rather than a cleaner (IMHO) approach of creating some data store project that uses EF internally, but exposes only POCO to its users. Why do all articles on the EF seem to ignore this (am I missing something). Thanks.</p>