分享一个优秀的开源ORM框架 -- petaPoco

hyblusea 2013-02-26 02:34:12

加精

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.实例化:

DataBase db = new Database(ConfigurationManager.ConnectionStrings["XE"]);

2.查询:

var v = db.Fetch<cls>("")

3.增 / 改 / 删



Cls.Insert();  

cls.Update(); 

Cls.Delete();

支持事务以及多实体关联, 更详细的使用可以参考官网给出的Demo: http://www.toptensoftware.com/petapoco/

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

T4对Oracle支持并不好, 有比较多的Bug, 因此我把项目中遇到的Bug, 以及需要修改的地方:

1.T4实体类的Update方法 , 根据ModifiedColumns 是否为Null判断实体中是否被更新,需要修改 PetaPoco.Generator.ttinclude文件第114行, 改为 if (ModifiedColumns == null || ModifiedColumns.Count == 0) 进行判断.

2.模板所生成的所有类,主键是否为自增属性始终为true, 原因 PetaPoco.Core.ttinclude 中的OracleSchemaReader 类, LoadColumns方法中 col.IsAutoIncrement 始终为true, 改为:
col.IsAutoIncrement=col.PropertyType != "string";

3.Oracle 数据库数据类型字段允许为空, 但类型中没有自动加上"?"
修改PetaPoco.Core.ttinclude第1216行, 将"YES"改为"Y", col.IsNullable=rdr["IsNullable"].ToString()=="Y";
并在第179行, 增加 col.PropertyType !="DateTime" 判断.

其他Bug不再一一列出, 最后附上T4 模板的调试方法,方便大家遇到问题自己快速定位和优化 :
1. .ttinclude文件的第一行修改为 <#@ template language="C#" debug="true" hostspecific="True" #>
2. 在需要调试的代码片断附近加入: System.Diagnostics.Debugger.Launch();

...全文

19683 163 打赏收藏转发到动态举报

写回复

用AI写文章

163 条回复

切换为时间正序

请发表友善的回复…

发表回复

sdsadasdas213123 2014-07-02

打赏
举报

请问下楼主如果我在连接完一个数据库后想连接另一个数据，petapoco该如何动态新建一个连接？

feimeng227 2014-07-02

打赏
举报

showjim 2014-01-16

打赏
举报

引用 160 楼 yuanlairen 的回复:

那么如果有了缓存技术，要考虑缓存哪些数据。如果一个查询涉及到多个实体集合，而每个实体集合对应的表数据量比较大，而查询条件也相对复杂，那么针对这种情况，可能是实体会约束或限制到表结构的设计了。本来一个简单的join和两个索引在db层返回1000条数据，而放到对象缓存来做，可能是得不偿失。毕竟有些查询是不太常见的，缓存的必要性和命中率是需要考虑得。而petapoco正是一个轻量的、高效的、灵活的、可控的组件，在应用中分情况使用各种技术，恐怕会比较好一点。

缓存应用不仅仅要考虑缓存哪些数据（比如可以缓存某几个查询列，可以缓存某个Key的Sum），还要考虑使用什么数据结果缓存数据（尽可能做到O(1)或者O(log(n))定位）。实体对于表结构设计没有副作用，相反的还可以减少某些物理索引或者计算列的设计。很久以前，缓存的命中率确实是个重要的问题，因为内存显得比较昂贵。个人认为现在对于服务器端开发，大缓存的使用带来的开发快捷与运行高效，相比于内存价格还是很划算的。正是这个原因，我还特意自己写了一个可嵌入的内存数据库引擎。如果是没有服务器端的客户端软件，我想数据查询很可能是无所谓效率的。

yuanlairen 2014-01-15

打赏
举报

引用 109 楼 sbwwkmyd 的回复:

[quote=引用 104 楼 qqqq764065388 的回复:] 在实践中ORM常常有短板，对复杂的查询力不从心，我觉得ORM是一个理想化的东西。

当ORM配合缓存使用时，多数复杂的查询都可以拆解成简单的查询。还有很多时候，复杂的查询之所以存在，很可能是数据库设计有问题。[/quote] 对你大部分的观点都比较认可：包括orm实现的对sql的抽象、面向对象等特点、强类型检查、带来linq的便捷等，以及实体对缓存技术的便捷使用。但对于复杂查询来说，可能不一定是数据库设计问题，从本质来讲，如果单从查询效率（没有应用程序缓存技术）来说，多加一层orm，应该是没有单纯的存储过程和sql来得快；那么如果有了缓存技术，要考虑缓存哪些数据。如果一个查询涉及到多个实体集合，而每个实体集合对应的表数据量比较大，而查询条件也相对复杂，那么针对这种情况，可能是实体会约束或限制到表结构的设计了。本来一个简单的join和两个索引在db层返回1000条数据，而放到对象缓存来做，可能是得不偿失。毕竟有些查询是不太常见的，缓存的必要性和命中率是需要考虑得。而petapoco正是一个轻量的、高效的、灵活的、可控的组件，在应用中分情况使用各种技术，恐怕会比较好一点。

yrmelody 2013-04-15

打赏
举报

这个可以有.我很喜欢这个框架.确实不错~

albertausun 2013-03-21

打赏
举报

谢谢各位老师辛勤付出，分享精神让人感动！

fhphappy 2013-03-14

打赏
举报

谢谢了我是新人来看看

月影 2013-03-11

打赏
举报

引用 92 楼 xxyj6450 的回复:

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

大哥：一个好的设计应该是存储无关的。也就是说，我可以把数据只存储在内存里，我也可以存储在文件里，数据库里等等。你用了DataTable，这是一个跟数据库绑定的概念。虽然你可以将数据放在DataTable而不保存到数据库里。但是你是去了强类型，编译时检查等等很多优势！这时候使用Domain Model是最好的选择。