应该是“DbContext”和“DbSet”暴露于纯POCO应用程序 [英] Should "DbContext" and "DbSet" be exposed for a pure POCO application
问题描述
通常会创建一个使用DbContext的服务层(例如基于Repository模式)。它的作用是在数据库和应用程序/客户端之间进行调停。它将接受来自客户的POCO并将POCO返回给客户端。这样一来,客户端就知道存储库,但是它并不了解DbContext。
有些更多的阅读方式:
http://blogs.microsoft.co.il/blogs/gilf/archive/2010/01/20/using-repository-pattern-with-entity-framework.aspx
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.
You would usually create a service layer (based on the Repository pattern for example) that makes use of DbContext. Its role is to mediate between the database and the application/client. It will accept POCOs from the client and return POCOs to the client. That way, the client knows about the repository, but it doesn't know anything about DbContext.
Some more reading for you:
http://blogs.microsoft.co.il/blogs/gilf/archive/2010/01/20/using-repository-pattern-with-entity-framework.aspx http://blogs.msdn.com/b/adonet/archive/2009/06/16/using-repository-and-unit-of-work-patterns-with-entity-framework-4-0.aspx
这篇关于应该是“DbContext”和“DbSet”暴露于纯POCO应用程序的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!