32、最简单的mvc框架tiny,orm、原理图、问题与解决思路

原创
2014/04/13 19:13
阅读数 1.3K

orm

先说下orm,在前面我们没有提这个,其实我们已经实现了orm功能。

这里把orm做了极大的简化,以一个model映射到数据库的一张表。在前面看到我们把业务处理也放在model里,所以这时model才是真正的充血模型,并把对数据库的操作封装为dao,所以orm其实为model+dao。

Tiny v1.0框架原理图

再补一下框架的原理图

Tiny v2.0 设计中。。。(先贴个图)


Tiny框架的问题及解决思路

问题1:参数类型Map<String,String>问题

我们规定所有参数都为Map<String,String>,中值都为String类型确实有点不好让人接受(虽然从页面传递过来的,都是String类型),现在我们想参数转型的工作由tiny来完成,我们怎么解决这个问题呢?

解决思路:

重写一个TinyMap类继承HashMap。我们实现getInt,getString等方法,调用这些方法可以对类型自动转换,当使用get方法时,其实是调用HashMap的get方法,放回object类型,代码如下:

TinyMap tMap = new TinyMap(参);
tMap.getInt(key);
tMap.getString(key);
tMap.get(key);//Ojbect

然后由前置控制器中将页面的参数转换为TinyMap类型(现在转换为HashMap),最后放入action参数中。由于action中参数为map接口,所有对原设计无影响,用户可同时使用HashMap和TinyMap的方法。

问题2Aop功能太过鸡轴,只能对action访问的织入,而不能对业务(model)织入

解决办法

方式1:动态代理模式

实现动态代理类。在前置控制器中代码Container.inject(o);(注入模型)时,注入代理类,然后在BindingAop中绑定model(类似action),代理类调用具体的model方法,在执行前后调用aop的before和after。具体如下:

BindingUtil.binding("/模型类/模型方法/", new Class[]{TestAop.class});//模型和aop的绑定
通过绑定,我们把模型类,自动放入代理类中,然后在action中定义代理类,同以前那样注入,然后action中调用代理类.invok();即可。

缺点:

方式1有个缺点,或者说是java的动态代理模式的缺点(也许大家好的办法,请告诉我下),就是必须得实现接口。实现一个接口一般没什么不好,但是咱们的模型是有很多个的,让用户去自己弄接口然后自己实现,这样也没什么不对,只是这样用户开发时,尤其是非常小的系统时,开发时就会很麻烦,这样有违咱们当初设计tiny的初衷,所以放弃方式1.

方式2:神秘方式

呵呵,我想到了一个变态的方式,以前看过别的框架实现过,觉得真是麻烦(需要用户去自己弄好多东西),我现在决定改一下,我自己感觉还不错,而且没有方式1的麻烦问题,在action中的模型,还是用户自己写的模型类,也不需要用户像绑定action那样去绑定模型和aop的关系,感觉一个action绑定就够了。就是说用户在什么也没做的情况下就有了aop的功能,是不是很神秘啊,很符合tiny的隐形特性。这个先买个关子,先不说明,等大家看见代码就一下明白了。就让它在神秘下吧。


展开阅读全文
打赏
2
43 收藏
分享
加载中
青青小树博主

引用来自“S1ahs3r”的评论

原理图有个地方应该改一下前置分发器->核心容器.毕竟bean跟context类似物在其中.
感觉并没起到dispatch的作用,流程控制都不是这个做的,请求映射是注解,视图渲染是根据Action返回值拿不同的渲染器

引用来自“永恒.”的评论

确实吧,容器忘记了,前置分发器都是从容器获取action等信息的 “感觉并没起到dispatch的作用,”这个所有的用户action请求都是先到前置分发器,由它来决定把这个请求交给谁来处理,我写的比较简单,调用action的代码也写到这里了,分开就好了,然后前置分发器我开始想是做异步的,就是接受到用户请求,分发给action(比如从线程池里取一个线程),它的工作就完事了。

引用来自“Slahser__”的评论

关于未实现的地方有一个地方挺期待的,没有做过.就是异步servlet跟listener. 期待博主写出来学习下,哈哈

http://my.oschina.net/eternal/blog/271639 上面是v2地址,已经实现了异步
2014/06/02 08:37
回复
举报
青青小树博主
http://my.oschina.net/eternal/blog/271639
上面是v2地址,有示例项目,可以看下
2014/06/02 08:37
回复
举报

引用来自“S1ahs3r”的评论

原理图有个地方应该改一下前置分发器->核心容器.毕竟bean跟context类似物在其中.
感觉并没起到dispatch的作用,流程控制都不是这个做的,请求映射是注解,视图渲染是根据Action返回值拿不同的渲染器

引用来自“永恒.”的评论

确实吧,容器忘记了,前置分发器都是从容器获取action等信息的 “感觉并没起到dispatch的作用,”这个所有的用户action请求都是先到前置分发器,由它来决定把这个请求交给谁来处理,我写的比较简单,调用action的代码也写到这里了,分开就好了,然后前置分发器我开始想是做异步的,就是接受到用户请求,分发给action(比如从线程池里取一个线程),它的工作就完事了。

关于未实现的地方有一个地方挺期待的,没有做过.就是异步servlet跟listener. 期待博主写出来学习下,哈哈

2014/04/14 12:57
回复
举报
青青小树博主

引用来自“S1ahs3r”的评论

原理图有个地方应该改一下前置分发器->核心容器.毕竟bean跟context类似物在其中.
感觉并没起到dispatch的作用,流程控制都不是这个做的,请求映射是注解,视图渲染是根据Action返回值拿不同的渲染器

确实吧,容器忘记了,前置分发器都是从容器获取action等信息的 “感觉并没起到dispatch的作用,”这个所有的用户action请求都是先到前置分发器,由它来决定把这个请求交给谁来处理,我写的比较简单,调用action的代码也写到这里了,分开就好了,然后前置分发器我开始想是做异步的,就是接受到用户请求,分发给action(比如从线程池里取一个线程),它的工作就完事了。

2014/04/14 08:54
回复
举报
真是十分感谢楼主这个项目,感觉对mvc的理解通透了许多.最近脑子里的东西也串了起来,还是老乡,0
2014/04/13 23:55
回复
举报
原理图有个地方应该改一下前置分发器->核心容器.毕竟bean跟context类似物在其中.
感觉并没起到dispatch的作用,流程控制都不是这个做的,请求映射是注解,视图渲染是根据Action返回值拿不同的渲染器
2014/04/13 23:44
回复
举报
0
2014/04/13 22:29
回复
举报
青青小树博主
:-)
2014/04/13 19:31
回复
举报
TinyMap 这个思路很好啊,要不就得自己强制转,泛型只能适合同一类参数,像既有String、int等的,确实比较麻烦。
2014/04/13 19:28
回复
举报
更新好快啊
2014/04/13 19:25
回复
举报
更多评论
打赏
11 评论
43 收藏
2
分享
返回顶部
顶部