博客园在推广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更适合复杂的系统（这里使用复杂，而不是大型），而不是小的系统，因为这样的系统要求建造速度快，系统稳定，他们的业务规则异常的复杂，但他们对系统的性能要求并不是很高（相对电信这样的性能要求）。