最近在 PHPChina 上看到一篇帖子，问到“大家习惯用原生SQL语句还是用框架封装的DB类？”。这里所谓“原生 SQL 语句”就是指手工书写的 SQL 语句，而不是框架自动生成的 SQL 语句。
对于这个问题，有些开发者认为根据个人习惯选择就行了。但是我认为这里面实际上有个深层问题，那就是框架的设计思想对开发者的影响。
如果框架的数据库服务仅仅是“简化数据库操作”，那么使用原生 SQL 就无所谓。因为用框架数据库服务的核心思想就是用自动生成的 SQL 语句来完成大部分常用的数据库操作，从而达到简化开发提高效率的目的。
遵循这种设计思想的框架，不管其数据库功能有多么强大，本质上仍然是围绕“数据”提供服务。所以查询的结果，显然就是一个个的数组。即便提供了 ActiveRecord 模式，也仅仅是数组的简单的封装。
在这种框架中，数据是数据，逻辑是逻辑，两者是分离的。就好像 FleaPHP 的 TableDataGateway 功能强大，而且能够自动处理关联表数据。但归根结底仍然是以简化数据库操作为目的来设计的，并不是要替代数据库操作。
而 QeePHP 则使用全功能的 ActiveRecord 来实现完整的 ORM 系统。所有的数据都转变为了对象。数据转变为对象后，数据和逻辑就封装到了一起。这才是真正的面向对象设计。
此时，框架实际上提供了对象持久化服务和底层的数据库服务两个重要层次。
对象持久化服务为对象和对象间关系的持久化提供帮助，让开发者不需要操心如何存储、查询一个对象，并且框架能够自动维护对象间的关系。而底层的数据库服务则退居幕后，大多数时候仅仅是为对象持久化服务层提供对象 <-> 数据库记录之间的互相转换功能。
在这种框架中，如果使用原生 SQL 就需要仔细考量一下。因为原生 SQL 查询出来的结果不是对象，所以无法利用封装在数据之上的业务方法。
对于 CakePHP、CodeIgniter、FleaPHP、ThinkPHP、Zend Framework 这些框架，它们的数据库服务的核心思想还是为“数据”服务，而不是为“对象”服务。这些框架的数据库访问服务，实际上是“加强版”的 adodb。再华丽的功能都只是为了简化“数据”的操作。因此在这些框架里面使用原生 SQL 并不存在什么问题。
如果是 Symfony、QeePHP 这样提供完整 ORM 能力的框架，框架的数据库服务层仅仅是为对象持久化提供的基础服务。框架是围绕“对象”来设计和实现的。对象封装了数据及其行为，应该尽可能使用框架提供的数据库查询服务。在这种框架中，开发者不应该以数据库的角度来考虑问题，而是应该以对象的方式来思考。这和传统的“数据库为核心”的设计有本质区别。
所以，到底选择原生 SQL 还是框架自己的数据库查询功能，应该根据框架的特点和应用的需求来确定，而不是根据开发者的个人习惯来选择，不然只能证明你选择了不合适的框架。
由此可见，框架的设计思想显著影响了开发者的解决问题的模式。并且对应用程序的设计和实现产生了实实在在的影响。
有兴趣深入的朋友可以看看《领域驱动设计》和《企业应用架构模式》这两本书，一定会有新的想法。