应用越复杂，维护成本就越高。特别是在涉及到应用逻辑的部分，如何提高开发效率、简化维护，对一个需要长期支持和更新的项目来说尤为重要。
在QeePHP 2.1中，模型的规格定义通过一个单独的静态方法来返回。虽然简单有效，但是并不直观，而且难以维护。早在几个月之前开发QeePHP 2.2的过程中，我就计划采用更拉风的DataMapper模式来替代ActiveRecord模式。不过最终实现的结果和DataMapper和ActiveRecord都有点区别，算是个混血儿吧。
下面是一个模型的源代码（节选）：
namespace game\models\users;
use qeephp\storage\BaseModel;
/**
* 玩家
*
* @domain main_db
* @collection user
*
* @use config: modelCache
* cacheTtl: 86400
* cacheMode: afterRead, afterSave
*/
class Player extends BaseModel
{
/**
* 玩家 UID
*
* @var serial
*/
public $uid;
/**
* 玩家名字
*
* @var string
* @internal
*/
public $name = '';
/**
* 等级
*
* @var int
*/
public $level = 1;
/**
* 虚弱状态过期时间
*
* @var int
* @fieldName tasks_bit
*/
public $tasksBit = 0;
......
/**
* 增加玩家的经验值，如果达到升级条件则同时提升玩家等级
*
* @param int $exp
*/
function incrExp($exp)
{
$this->incrExp += $exp;
$this->exp += (int)$exp;
while ($this->exp >= ($nextLevelExp = $this->nextLevelExp()))
{
$this->level++;
$this->exp -= $nextLevelExp;
}
}
......
}
模型的定义与Sexy ORM这篇文章的描述有所区别。趋向于更简单、更容易理解。
与QeePHP 2.1相比。在新的架构中，仍然由Meta对象维护模型的规格定义。而具体的存储操作则直接委托给存储服务。存储服务可以是传统的MySQL数据库，也可以是新潮的Monogodb，或者是Memcached。
常规用法
// 查找特定主键值的对象 $player = Player::one($playerId); // 查找多个主键值的对象 $players = Player::multi($somePlayersId); // 删除指定主键值的对象 Player::del($playerId); // 保存修改 $player->save();
总的来说，接口比QeePHP 2.1简化了很多。主要原因是因为QeePHP 2.2是在开发公司的SNSGame时逐渐完善的。面对SNSGame的海量用户，简单的接口不但降低开发难度，而且也能够很好的适应灵活的架构。
当然，由于插件接口的存在，要扩展出灵活的查询方法是很轻松的事情。尽量保持核心的最小化也是QeePHP 2.2的主要目标之一。
沙发…
廖老大，这么爽的特性都只能在php5.3+才能体验了吧？
目前的2.1还会有大的变动么？
肯定是5.3+撒，5.3的新特性很好用。
QeePHP 2.1不会有什么改动了。
2.2发布了？
建议能把项目放到SVN上。。
呵呵
…..支持啊 呵呵 我写想写框架 廖大的框架是我认为最好的 QQ都咨询了 没回 呵呵
呵呵。。 框架是不错滴
不过动态却不好。
官方也很久没动静了。
目前在用YII。对QEE观望。
5.3有了延迟绑定，真是大快人心啊。。哈。。。我也仿照phpactiverecord写了个貌似activerecord的东西来用，可惜公司服务器不支持5.3，最后按照QEE的方式加个META对象来做了。。。
有点意思！
发现单入口应用程序会有堵塞问题……….
啥堵塞？