前段时间初步学习了LINQ，感觉确实是很好很强大，LINQ To SQL实现了用面向对象的方式来操作数据库，开发效率也大大提升，具体优点也不用多说，相信了解过的朋友比我还清楚。
纵观这几年.NET的发展，在.NET 1.1时代，建立数据库访问层可能就像PetShop4.0中的代码差不多，创建一个业务实体类，然后用泛型对业务实体进行包装，于是在业务逻辑层中就可用面向对象的方式通过数据访问层访问和操作数据库了，此过程需要手动编写大量代码才能完成数据访问层的编写。
到了.NET 2.0时代，有了强类型Dataset和ObjectDatasource等，完成数据访问层也简单了许多，很多实质性的工作实际上都由Visual Studio 2005的Designer自动生成了，缺点就是自动生成的代码进行跨表操作很困难。
而到了.NET 3.5(LINQ在.NET 3.0中就已出现),通过LINQ To SQL，我们也可自动生成相关代码，并能以完全面向对象的方式访问和操作数据库，跨表操作也轻而易举，开发效率进一步得到大大提升，可以说达到了数据访问方法的一个顶峰。
从以上数据访问技术的演变可以看出，微软是千方百计地想进行关系型数据查询与操作的面向对象化，但一个实质性的问题始终没有办法解决，那就是数据库的可扩展性、可维护性和灵活性还是太差。举个例子说吧，假如开发过程中数据库架构发生变化，则这种变化对数据访问层是灾难性的，没有解决方法，只能重新生成代码，重新编译，此变化可能还会影响到业务逻辑层和界面层。如对于一个已经发布出去的系统来说则更是致命。这些问题不管用强类型DataSet还是LINQ To SQL都无法解决，当然原因不在强类型DataSet和LINQ To SQL本身，他们只是访问数据库的一种技术，根本原因是因为数据库是关系型的，而不是面向对象的，这造成了在数据访问层中很难运用一些面向对象思想(如设计模式，设计模式用得最多的地方是在业务逻辑层)来提高可扩展性、可维护性和灵活性，所有个人觉得一个面向对象数据库的问世对于如今面向对象的时代绝对是一个革命性的成果，也必将颠覆以往的开发模式。试想有了面向对象的数据库，配合合理的设计模式的运用，建立一个灵活、可扩展、能适应需求变化的数据库后，底层的变化就可尽量不对上层产生影响，我们在上层代码就可专心进行业务逻辑的处理了。
其实个人觉得LINQ已经非常接近这一目标了，微软既然做到了这一步，为什么不直接开发一个面向对象的数据库，就像使用LINQ来访问、操作数据库而不像现在这样使用LINQ在对象与关系间进行映射、转化和隔离了。
从目前来看，面向对象数据库好像还停留在理论上，这么多年过去了还是没有出现!
原文连接：http://gyche.cnblogs.com/
