什么是实体框架与POCO [英] what is Entity Framework with POCO
问题描述
什么是使用POCO的好处？我不明白，持久性无知的意思，这是什么意思？那POCO对象不能暴露之类的东西保存？我不能完成我的头，围绕这POCO是有很多议论周围。
What is the benefit of using POCO? I don't understand the meaning of Persistence Ignorance, what does this mean? That the poco object can't expose things like Save? I can't wrap my head around this POCO that there's alot of buzz around.
与EF产生的实体和POCO？
What is the difference with the EF generated entities and POCO?
推荐答案
POCO表示普通老式C＃对象或普通老式CLR对象，这取决于谁你问。如果一个框架或API指出，它运行在POCO的，这意味着它允许您定义的对象模型的惯用中，而不必让你的对象从特定的基类继承。一般来说，在POCO的这项工作框架，让你更大的自由和控制你的类的设计和实施，是因为他们有较少的要求才能正常工作。
POCO stands for "Plain Old C# Object" or "Plain Old CLR Object", depending on who you ask. If a framework or API states that it operates on POCO's, it means it allows you to define your object model idiomatically without having to make your objects inherit from specific base classes. Generally speaking, frameworks that work on POCO's allow you greater freedom and control over the design and implementation of your classes, because they have fewer requirements to work correctly.
持久性的无知意味着，尽可能多地，什么都在你的code。在商业逻辑层或更高的工作一无所知数据库的实际设计中，你正在运行的数据库引擎，或如何或何时对象获取检索到的或持久化到数据库。在MEF的情况下，持久性无知是由工作在POCO的和使用LINQ执行查询获得（即，不要求用户创建任何SQL查询来检索所需的对象）。
Persistence ignorance means that, as much as possible, anything in your code operating at the business logic layer or higher knows nothing about the actual design of the database, what database engine you're running, or how or when objects get retrieved from or persisted to the database. In the case of the MEF, persistence ignorance is attained by working on POCO's and using LINQ to perform queries (i.e., not requiring the user to create any SQL queries to retrieve the desired objects).
这是一个悬而未决的问题，但它普遍认为，在大多数情况下，域对象（或业务对象 - 无论哪种方式，在POCO的上面提到的）应该是无知的持久性逻辑。含义，而不是打电话， MyBusinessObject.Save（），你有一个IO管理或适配器类，你叫 Manager.Save（MyBusinessObject）。通过这种方式，你避免暴露持久性语义上的业务对象 - 你得到更好的关注点分离这样
It's an open question, but it's generally agreed that under most circumstances, the domain objects (or business objects - either way, the POCO's mentioned above) should be ignorant of persistence logic. Meaning, instead of calling MyBusinessObject.Save(), you have a IO manager or adapter class, and you call Manager.Save(MyBusinessObject). In this way, you avoid exposing persistence semantics on your business objects - you get better separation of concerns that way.
这篇关于什么是实体框架与POCO的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
