我们为什么使用ORM
博客园在推广ORM方面的确做了很大的贡献,很多的程序员开始使用ORM,不用写SQL的喜悦让他们激动不已,可是好景不长,他们很快发现众多的烦恼一个接一个的出现了。
很遗憾,我并不打算在这篇文章中解决这些问题,因为的确存在这些问题,而且目前没有完美的解决方法。那么既然这样,我们为什么要使用ORM呢?难道真的是为了不使用SQL吗?
还是要看O - R ,我们为什么要将关系型的数据转化成Object的方式,DataSet的方式难道不好吗?和数据库的表现还是很一致,又简单又方便,为什么先辈们要兴师动众的转化为Object。
我们知道,Object是可以继承的,是可以使用接口的,而Relation没有这个概念。就是因为这一点,我们将实体设计成Object方法,从而获取了大量的优势。
例如:我可以在程序中检测实体是否支持IVersionObject接口,如果支持,我们将自动做版本控制,而如果你给我一个DataSet,那我将无法检测(不要告诉我检测是否存在Version字段)。通过这个特性我们将可以自动化处理很多的事情。
又如,我设计了一个单据实体的基类,包含了SheetCode、SheetDate等等字段,然后我的OrderSheet继承自SheetBase,他们将自动获取到这些标准的字段,而且我的基础类可以自动帮助我处理很多统一的规则,使程序更加稳健和统一。而这个Relation的东西是非常难做到的。
市面上有很多的ORM系统,鱼龙混杂,事实上,相当多的系统根本无法利用Object的继承特性,他们还是一堆的如何做一对多、多对多的概念。根本没有了解到ORM的精髓就做出来。
在这里我需要解释几个误解:
1、ORM使我们摆脱了SQL,但并不代表我们不再使用SQL,事实上,复杂的查询和报表我仍然推荐使用SQL,良好的系统应该可以兼容以前的方式;
2、微软在表模型(Relation)上花费了无数的精力,所以目前Relation的一揽子解决方案是最完整,最好的。但我们看到,微软在.NET 2.0中对Object方式的绑定支持更近了一步,随着LinQ、XAML等很多后续技术的发展,相信领域模型(Object)的完整解决方案将更加完整;
3、ORM更适合复杂的系统(这里使用复杂,而不是大型),而不是小的系统,因为这样的系统要求建造速度快,系统稳定,他们的业务规则异常的复杂,但他们对系统的性能要求并不是很高(相对电信这样的性能要求)。
很遗憾,我并不打算在这篇文章中解决这些问题,因为的确存在这些问题,而且目前没有完美的解决方法。那么既然这样,我们为什么要使用ORM呢?难道真的是为了不使用SQL吗?
还是要看O - R ,我们为什么要将关系型的数据转化成Object的方式,DataSet的方式难道不好吗?和数据库的表现还是很一致,又简单又方便,为什么先辈们要兴师动众的转化为Object。
我们知道,Object是可以继承的,是可以使用接口的,而Relation没有这个概念。就是因为这一点,我们将实体设计成Object方法,从而获取了大量的优势。
例如:我可以在程序中检测实体是否支持IVersionObject接口,如果支持,我们将自动做版本控制,而如果你给我一个DataSet,那我将无法检测(不要告诉我检测是否存在Version字段)。通过这个特性我们将可以自动化处理很多的事情。
又如,我设计了一个单据实体的基类,包含了SheetCode、SheetDate等等字段,然后我的OrderSheet继承自SheetBase,他们将自动获取到这些标准的字段,而且我的基础类可以自动帮助我处理很多统一的规则,使程序更加稳健和统一。而这个Relation的东西是非常难做到的。
市面上有很多的ORM系统,鱼龙混杂,事实上,相当多的系统根本无法利用Object的继承特性,他们还是一堆的如何做一对多、多对多的概念。根本没有了解到ORM的精髓就做出来。
在这里我需要解释几个误解:
1、ORM使我们摆脱了SQL,但并不代表我们不再使用SQL,事实上,复杂的查询和报表我仍然推荐使用SQL,良好的系统应该可以兼容以前的方式;
2、微软在表模型(Relation)上花费了无数的精力,所以目前Relation的一揽子解决方案是最完整,最好的。但我们看到,微软在.NET 2.0中对Object方式的绑定支持更近了一步,随着LinQ、XAML等很多后续技术的发展,相信领域模型(Object)的完整解决方案将更加完整;
3、ORM更适合复杂的系统(这里使用复杂,而不是大型),而不是小的系统,因为这样的系统要求建造速度快,系统稳定,他们的业务规则异常的复杂,但他们对系统的性能要求并不是很高(相对电信这样的性能要求)。