这一段时间都在弄HBase、Hadoop相关的东西，事情多，压力也挺大的，一直来不及写博，今天算是忙里偷闲把这篇补完吧。自己本身也只用到了一部分，有些还是比较模糊的，等以后用的时候再看吧，现在算是总结一下。
用top开独立网店的话，其实很多东西都是要用taobao的API的，其实操作都是在taobao上完成的，首先要理解这一点，比如以前的用户购买记录之类的，一般都是存放在taobao上的，如果你要读的话当然也可以从那边抓来。可以参照ucenter模块，再看看它里面用到的membergrade，大概就可以清楚这个流程了。
模块启用完毕后，在template里添加对它的引用，比如<tb:modele name=”comment” id=”1″>，这样的一个引用被称作模块的实例，instance。加入这个概念应该是因为模块在不同的地方被引用可能表现出不同的行为吧，可以在sellercmd等模块中看一下它的用法（这个地方我理解不是很深入，可能有错误）。
接下来也不知道从哪说起，反正都是很散的东西，虽然大的框架理解了，但这些小的地方还是花了我比较多时间，在自带的那些module里面去找哪些功能怎么实现。于是就按照开发手册左侧的类的顺序来吧。
Tom_Admin_Module Tom_Admin_Template 用来管理的模块，可以得到已经安装的模块内容、配置文件、后台使用的模板等。如果不做后台开发的话应该用不到这一块
Tom_Biz_Item_Skuitem这一块应该是将taobao的商品与专家自有的ERP结合起来吧，就是将它们的字段对应一下。在这里我必须吐一下槽，这个我之前没看懂因为我根本不知道这sku是个啥玩艺。后来好像是套餐。就不能有一个地方稍微说明一下吗。然后这ERP是哪里来的我也不知道。找了找没有什么信息。
Tom_Biz_Order_* Tom_Biz_Trace_* 开头的这一串，就是订单交易相关吧，没啥好说的。
Tom_Util_* 这些则提供了一些常用的函数，比如过滤啊，分页啊，是静态的可以直接Tom_Util_Filter::filterContent这样调用。分页的比较复杂，我相信只看手册肯定是看不懂的。不过看看article里的listAction大概便明白了吧。
Tom_Biz_Item_* 通过API从taobao查询取得商品信息
Tom_Biz_Combo_* 你没有看错，是Combo而不是sku。但实际是一样的，有点混乱的命名吧，不过我觉得Combo更好理解一点恩。这一块基本同上，不过这里的操作大多是在本地数据库中进行，这里我不是很理解。
Tom_Admin_Menu – Tom_Template 这块都还比较好理解的，有关配置、错误、工厂类之类的东西，看看它本身的就够了。
接下来又是一堆Util比较有用的应该是Tom_Util_Common(可以得到BossNick)、Tom_Util_Memcache(缓存，加快速度)、Tom_Util_PageCache(缓存整个页面)、Tom_Util_TMCookie(我不知道这哥们和上面的TMACookie到底有啥区别，猜测上面的是给店长或店员用的？)、Upload那些类应该是添加宝贝时上传图片用的比较多，别的场合可能还不太用的上。
在core的部分，以Admin开头的主要是后台，Core开头的则是前台，Commands一般都用不到。Action相当于一般controller，主要是实现控制逻辑，一般的功能主要是转向、渲染视图。注意这里的转向有好几种：redirect, redirectError, forward等等，不要用错了。而render()之后程序不会自动退出的，要手动调用return or exit()。
Filter类主要是访问权限控制和修饰处理结果。
Request Response 包含了对这个页面请求的信息和返回的信息，比如获取和设置cookie都是在里面。Response里有设置javascript和css文件的函数，但是我怎么都调用都没有效果。最后是用的actions里的类似函数。
Router 的作用一看名字就知道，大概就是操作url，设置url映射，生成外部url之类的，这里还有一些另外的函数，看说明便可以知道。
Db段有这么多class，其实基本只有两个有用：Tom_Db_Table和Tom_Db_Record，很简单，一用便知。
log类我没用过。Acl访问权限这边估计下一个就要用到了，到时候再看吧。
top段下面全都是可以用的api，觉得这里的说明不够详细的话就看taobao官方的api文档吧，使用方式就是先得到一个Tom_Top_Client的对象，然后再用$client->userGet()这种方式就可以调用了，在Request_后面的是API名称，将第一个字母小写就是函数名了，比如Tom_Top_Request_UserGet对应的就是userGet()这个函数。
就写这些吧，有些遗漏的话是我觉得不是很重要的，等用到的时候再看就好了，多去看本身自带的module和源码，应该是不会碰到什么问题的，就是开发效率低下一些。
上次写的一个管理系统，用CakePHP写的，都是默认设置，最后访问一个页面居然需要4.几秒钟。实在是让人受不了，提高速度的方法倒是很多的，但是，这让我开始思考一个问题，CakePHP有必要吗？
之前CakePHP用的最熟，写起来开发效率真的是很快，甚至觉得不用框架写PHP太dirty了，太低级了。以前实验室的项目用的ZF，其实基本就只用了一个url重写，别的全是手写的，特别是model层，裸的sql语句嵌入在php代码中。现在回想一下，的确是质量很差的代码，但写起来效率也高啊，访问速度也快。
接下来一段时间都比较纠结，如果要继续用CakePHP的话，那么其实虽然开发快了，但是要额外地对它的性能进行优化的话，加起来的工作量不会比写原始的php小多少。换一个框架也是一个选择，不过我开始想，我到底需要框架吗？特别是CakePHP这种比较重量级的，即使我写一个最简单的Hello World，它也要经历一个完整的bootstrap过程，甚至还会去实例化model对象，会describe 你需要的表。那么我最需要的到底是什么呢？最后总结出来其实很少：一个简单的mvc分层，一个url dispatcher。于是最后我选择了smarty，自己手动实现model层，url dispacther的话是美观要求，可以以后再加。这样又写了一个后发现其实开发效率也还是比较快的，由于逻辑也比较简单，所以维护代价也能让人接受。
现在想想ZF，以前觉得太像java，太笨重了，完全不符合php的理念，但现在却觉得它的耦合度还是很松的，你可以只用里面的一部分而重写另一部分，而这在CakePHP里就很难做到了。据说Kohana挺符合我的要求的，很轻量级。不过如果以后自己写的代码复杂起来了，那慢慢再将里面的东西抽象出来，也会形成一个框架了，所以，还不如写自己的吧。