分享一个优秀的开源ORM框架 - petaPoco,该怎么处理

分享一个优秀的开源ORM框架 -- petaPoco
petaPoco出现在2011年...因此老鸟可忽略该贴...目前最新版是 5.0, 但核心文件变化不大.

在众多的ORM框架中, 其中不乏非常优秀的EF, 但今天仍然想写点关于PetaPoco的文字 ... 是因为有几个项目一直在使用petaPoco, 原因有2点:
1. 轻量级, 高性能
2. 个人偏向DataBase First的开发方式, 原因在于Toad for Oracle工具创建数据库对象迅速, 各种方便, 胜过Code First模式创建类的速度.(此处抛开各种设计模式,各种理论).

------------------------------------------

开发准备:
1.通过Nuget添加 petaPoco的引用 
2.在app.config文件中加入 <connectionStrings> 节点, 并配置connectionString, providerName属性.
3.打开 DataBase.tt , 修改 ConnectionStringName,以及 Namespace , Namespace, 保存以后VS会自动执行模板文件,并生成实体类文件: DataBase.Cs

------------------------------------------

使用方法:
1.实例化:

有没有人测试过对mysql的支持怎么样？ 
 
[解决办法]
不理解ORM。
为什么从业务到数据，要加上ORM的这层面向对象的转换?效率低下，维护麻烦。
有点儿盲目追求面向对象不?
ORM的唯一价值就是帮助只懂面向对象，不懂数据库的同学来理解数据库。
所以我觉得ORM应只停留于理解与建模，不应再硬生生向代码转换。
[解决办法]
公司用的数据库是sql2000怎么办
[解决办法]
引用:
如果你认为写字段名比IDE自动提示更麻烦更可靠

如果你认为IDE自动提示比写字段名更麻烦更可靠
[解决办法]
引用:
不理解ORM。
为什么从业务到数据，要加上ORM的这层面向对象的转换?效率低下，维护麻烦。
有点儿盲目追求面向对象不?
ORM的唯一价值就是帮助只懂面向对象，不懂数据库的同学来理解数据库。
所以我觉得ORM应只停留于理解与建模，不应再硬生生向代码转换。

你真的OUT了，你难道以为微软提高的DataTable很通用？那个类只有在WinForm编程中才受欢迎，到了WPF、Silverlight乃至非.NET语言中，根本不存在这东西，那么要离线存储数据怎么办？只能放在实体类集合中去。
而且WPF对实体类集合的支持大大加强了，可以说，微软鼓励我们用ORM进行操作，不是因为不需要懂数据库，而是为了让界面控件能够自动化处理（绑定必需），你懂数据库了，界面控件不可能会懂。
[解决办法]
引用:
引用:不理解ORM。
为什么从业务到数据，要加上ORM的这层面向对象的转换?效率低下，维护麻烦。
有点儿盲目追求面向对象不?
ORM的唯一价值就是帮助只懂面向对象，不懂数据库的同学来理解数据库。
所以我觉得ORM应只停留于理解与建模，不应再硬生生向代码转换。
没有实体类程序，能简单高效的应用缓存技术吗？没有高效的缓存技术，如何……

1.应用缓存只能通过实体类吗?
2.面向对象讲究抽象，89楼有提到DataTable。你不认为Datatable是更抽象实体类吗?
3.我觉得IDE提示，面向对象啥的都是浮云，最终还是增删改查。并不一定要在代码里写一堆的SQL语句，SQL可以封装成数据库函数和过程
4.所以我说ORM的价值就是让程序员以自己熟悉的面向对象的方式来看关系数据库。
ORM一个最大的，也是我认为致命的缺点，它把原本简单的关系数据，完全转换成了更复杂的对象。对象远比关系数据复杂。ORM只是为了面向对象而面向对象。把一切都搞成面向对象。我认为只应该把少量固定的，稳定的，而且较为复杂的业务用面向对象来处理，而不是所有的业务。当你的业务复杂，需求多变，而且项目达到一定规模时，你不觉得维护这成百上千，甚至更多个类，会很痛苦吗?
[解决办法]
引用:
引用:不理解ORM。
为什么从业务到数据，要加上ORM的这层面向对象的转换?效率低下，维护麻烦。
有点儿盲目追求面向对象不?
ORM的唯一价值就是帮助只懂面向对象，不懂数据库的同学来理解数据库。
所以我觉得ORM应只停留于理解与建模，不应再硬生生向代码转换。
你真的OUT了，你难道以为微软提高的DataTable很通用？那个类……

我的确有点out了，我是从面向过程过来的，对面向对象不太友好，觉得被语言开发商过度神化了，不敢多用，对WPF、Silverlight都不了解，太多太杂了，根本学不过来。
关于离线存储，如果一定要存到实体类，那Datatable也未尝不可。另外，离线存储不可以存到磁盘，内存数据库吗?离线存储和ORM的关联很弱。
还有数据绑定，.NET没用过，在VB里有用过，挺简单，.NET里也可以绑定不?WPF不了解，没用过，ORM和数据绑定的关联也很弱吧?能用实体类的地方都可以用Datatable不?
其实Datatable我也几乎没用过，性能怎样不清楚，那是微软的事，我只知道它大概是个啥东西。

[解决办法]
引用:
引用:不理解ORM。
为什么从业务到数据，要加上ORM的这层面向对象的转换?效率低下，维护麻烦。
有点儿盲目追求面向对象不?
ORM的唯一价值就是帮助只懂面向对象，不懂数据库的同学来理解数据库。
所以我觉得ORM应只停留于理解与建模，不应再硬生生向代码转换。
orm能够方便的面向对象，之前的方式都是将数据塞到datatable……

所以我觉得ORM是为了面向对象而面向对象。
我觉得把数据全放到datatable这样的对象里挺好。
主程序代码只提供界面，并负责对datatable的增删改查，不管实际业务，更不用管业务的什么实体类。
业务的具体规则开发人员以插件或动态脚本的方式控制。
[解决办法]
ORM支持者无论采用DBFirst还是CodeFirst,都是数据驱动的开发思维,
以今天你的技术手段,ORM明显不能算是面向对象设计了,
以今天你的技术手段,完全可以把对象的重心放在了业务逻辑上
根本就不需要把数据库的东西在程序中重复一遍

还有,实体是抽象的业务类型的现实子类,
这个名词本身就是用来描述业务而不是数据的:
The existence of something considered apart from its properties
[解决办法]
引用:
1.应用缓存只能通过实体类吗?
2.面向对象讲究抽象，89楼有提到DataTable。你不认为Datatable是更抽象实体类吗?
3.我觉得IDE提示，面向对象啥的都是浮云，最终还是增删改查。并不一定要在代码里写一堆的SQL语句，SQL可以封装成数据库函数和过程
4.所以我说ORM的价值就是让程序员以自己熟悉的面向对象的方式来看关系数据库。
ORM一个最大的，也是我认为致命的缺点，它把原本简单的关系数据，完全转换成了更复杂的对象。对象远比关系数据复杂。ORM只是为了面向对象而面向对象。把一切都搞成面向对象。我认为只应该把少量固定的，稳定的，而且较为复杂的业务用面向对象来处理，而不是所有的业务。当你的业务复杂，需求多变，而且项目达到一定规模时，你不觉得维护这成百上千，甚至更多个类，会很痛苦吗? 
 

1.DataTable也能做缓存，只不过是设计与查询都不方便，而且效率低下。
 DataTable.Select查询的字段名与变量你能保证不拼写错误？DataTable中的数据使用可以不用重复拆箱操作吗？DataTable.Select的查询字符串不用解析？
 对于普通遍历查询，DataTable.Select能写那些表达式？相比于lambda如何？
 比如有个产品表，它有3个查询需求，根据 id、产品分类、产家id 取数据或者数据集合，要求增删改查时间复杂度都是O(1)的。请问用DataTable如何实现？
2.object抽象吗？你怎么会使用DataTable呢？再说DataTable也就相当于一个ICollection<Dictionary<string,object>>，ORM要添加个字典功能非常的简单，这样说来DataTable也就相当于ORM功能的一个子集而已。
 记住，抽象不是模糊，是共性。
3.SQL语句、数据库函数、存储过程，你统统用手写啊？我几年没在程序里面写过SQL语句了，ORM就是用来生成具有共性的SQL语句的，这就是一种抽象方法。而且这种抽象很容易与面向对象的程序融合在一起，SQL语句永远都只能是字符串。
4.所以我说DBA应该做好自己的事，不应该YY程序员应该怎么写程序。
引用:
我的确有点out了，我是从面向过程过来的，对面向对象不太友好，觉得被语言开发商过度神化了，不敢多用，对WPF、Silverlight都不了解，太多太杂了，根本学不过来。
关于离线存储，如果一定要存到实体类，那Datatable也未尝不可。另外，离线存储不可以存到磁盘，内存数据库吗?离线存储和ORM的关联很弱。
还有数据绑定，.NET没用过，在VB里有用过，挺简单，.NET里也可以绑定不?WPF不了解，没用过，ORM和数据绑定的关联也很弱吧?能用实体类的地方都可以用Datatable不?
其实Datatable我也几乎没用过，性能怎样不清楚，那是微软的事，我只知道它大概是个啥东西。

面向ORM的数据视图，不仅仅可以绑定数据，还可以绑定属性与函数。
ORM比较重要的突破就是树状数据视图，ORM所有关联关系都可以做到只需要处理一次，而且容易扩展；而DataTable仅仅是一个二维文本表格，所有不同关联需求都需要单独写SQL逻辑。
引用:
ORM支持者无论采用DBFirst还是CodeFirst,都是数据驱动的开发思维,
以今天你的技术手段,ORM明显不能算是面向对象设计了,
以今天你的技术手段,完全可以把对象的重心放在了业务逻辑上
根本就不需要把数据库的东西在程序中重复一遍

还有,实体是抽象的业务类型的现实子类,
这个名词本身就是用来描述业务而不是数据的:
The existence of something considered apart from its properties

ORM有不仅数据库驱动模式，还有程序元数据驱动模式。
正因为有了ORM，应用程序员才能够真正的把重心放在业务逻辑上，而不用在SQL语句费心思。
纠结名词的概念对于具体实现是毫无意义的。就算不用实体描述，ORM还是在哪里，它的价值还是在哪里。