2019独角兽企业重金招聘Python工程师标准>>> 
总结一下目前tiny的问题
前面已经说了2个：1、TinyMap和2、aop，TinyMap的思路我觉得挺好的，但是TinyMap类实现有点简单粗糙，需要增强。
aop，前面说的方式1，不合适tiny v1，方式2思路就是直接操作class字节码，添加aop的代码，这个jdk 1.5就开始支持了，1.6又增强这个功能，一些开源库都有实现如asm或一些aop框架，spring和hibernate也有用到，但我不想实现了，这个下面有提到原因。
3、设计的问题
tiny的开发属于临时起意，tiny的所有功能中，我觉得视图的处理，aop的绑定方式，mvc的路由，model和表自动对应，前置控制器的注解方式还可以外，其他的功能都实现的太差。
4、其他问题
- tiny v1的功能感觉就是在东拼西凑，没有一个整体的概念。
- ioc只是是把model的实例放入action，只能说有一点用。
- 还有aop的实现，前面说了只能对action（确实有的框架只是对action操作），action里没有业务所以根本不能把鉴权和日志织入到实际的业务中。
- model虽然是充血模型，但是具体的业务在model里处理，这已经超出了他的能力，就是我们又犯了一个错误，model太胖了。
- dao，一个要实现所有的数据库操作，真是不敢想象。
- 数据库连接池的实现，只能算是一个玩具。
- 还有一个忘记说了就是aop的调用方式太拙劣。
应该还有很多问题，大家有兴趣帮我指出，只要不骂人（脏话），我都会仔细看大家的提的。（我不是高素质的人，但是我保证，我从来没在群里骂过人）
分析一下解决的办法
首先解决整体概念问题：
v1的东拼西凑，是因为没有一个东西能起到连接或融合各个功能的作用。我想这个东西应该是ioc容器，他管理着action，service（业务），aop。就是说前置控制器找到要对应的action后，之后的事就是ioc的了；再有aop要有拦截链的概念，还有v1的aop里也没有当时执行的环境。
model太胖的问题：
太胖了就瘦身下，model里应该有业务的数据和产出或触发业务的行为的能力，然后由service处理具体的某个业务。这里应该是model调用service？这是最直接的想法，起码我是这么想的，但是就像action和视图一样，我们需要解耦这个关系，所以model没有直接调用service，model会发出触发了某业务的事件，具体由哪个service处理，model就不管了。这里我以前看到过一个牛x人做的形象说明：
你受到了拆迁部门不公平的拆迁政策，你到政府 来投诉，这时肯定会有一个人或一个部门来接待你，他们听了你的投诉后，不会处理你的投诉，会告诉你，我们知道这个事了，我把这个事交给有关部门来处理的，你放心吧。接待你的人或部门就是model，有关部门就是service，所以model只是 触发了这个 业务的事件而已。
dao里要有接口的概念，支持多数据库，像视图的多态。初步想，没想好。
数据库连接池的实现，呵呵，这个本来就是一个玩具，我没想把它弄的多么强大。但是我们会提供其他主流连接池的支持。
V2版思路
临时记录一下。
tiny v1功能不再更新，v2设计中，请稍候。。。