为什么 POCO 相对于 EF4、nHiberate 来说是个好东西
为什么在 EF4、Linq2SQL 或任何其他数据映射技术中支持 POCO 如此重要?我理解 OO 意义上的 POCO 概念,但是当涉及到 ORM 时我还缺少其他东西吗?
编辑:我只是在 ORM 的上下文中添加我个人对 POCO 的定义: 它是由开发人员手动编码的类,而不是由 ORM 映射工具(如 Visual Studio 的 EF4 设计器)生成、增强或注释的类。
如果我错了,请纠正我。
Why is it so important to support POCO's in EF4, Linq2SQL or any other data mapping technologies? I understand the concept of a POCO in the OO sense but is there something else I'm missing when it comes to ORM's?
EDIT: I'm just adding my personal definition of a POCO in the context of ORM's:
It is a class that is hand-coded by the developer as opposed to a class that is generated, augmented or annotated by a ORM mapping tool (like Visual Studio's EF4 designer).
Please correct me if I'm wrong.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

发布评论
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
“POCO”意味着框架不会对实体对象施加不必要或违反直觉的约束 - 不需要使用代码生成器,不需要扩展框架提供的基类,广泛注释属性,或者在大多数情况下必须,编写与始终存储在内存中的类不同的代码。这样可以保留模型类之外的持久数据,并减少认知开销。
将 NHibernate 或 EF Code First 中的 POCO 定义与 Visual Studio 为没有 Code First 的 EF 生成的代码进行比较,并问问自己您更喜欢阅读和维护哪一个。 (例如,当探索新的代码库时。)
"POCO" means the framework places no unnecessary or counterintuitive constraints on the entity objects – no need to use a code generator, no need to extend a framework-provided base class, extensively annotate properties, or to have to, for the most part, write different code than you would were the classes always stored in-memory. This keeps the concern of persisting data outside the model classes and reduces cognitive overhead.
Compare the POCO definitions from NHibernate or EF Code First with the code Visual Studio generates for EF without Code First and ask yourself which one you prefer to read and maintain. (When poking around a new codebase for instance.)