Ajax把MVC方式变成了"MV模式"

请暂且原谅本人的浅薄，原来有一篇blog写到我初次接触ajax觉得这玩意不过如此。如今本人却要来一个180度的转弯了，大家不要笑话，人认识事物是渐进的啊

最近才认真学习了ajax，目前已经在项目中应用了，感觉很好。我想大家都知道ajax的基本原理的，在此就不多说了。从这段时间的实践来看。我认为采用了ajax的网站，完全可以从MVC模式变为MV模式。

什么是MV模式，这是我的一个提法，只是把c给去掉了，相信很多人都有同样的想法，也许我有幸成为世界上第一个采用这一个名称的人。至少我在google上面没有查到有人用这个说法。所谓MV就是模型-视图模式。大家也许记得为什么当初要发明MVC模式。MVC的目的是为了实现表示层逻辑和业务逻辑的分离。这种分离的代价在当时的技术条件下，就是产生了称为controller的玩意。

只要写过struts的人都一定知道，虽然struts可以实现表示层逻辑和业务逻辑的分离，但这种分离是让人非常不愉快的。首先我们需要继承Action类，然后在这个类中写控制代码，最后有一个叫struts-config.xml的文件等待我们去配置。struts的controller是很难设计的，首先配置比较复杂。xml的配置文件毕竟是一个额外的文件，配置文件的确有好处，但如何维护配置文件是一个问题，如果你的项目中有人不小心错改了配置文件，恭喜你一个隐藏的bug就出现了。当然这不是struts的controller的罪恶，更不是MVC的错。更大的问题还在后面，那就是如何设计controller控制的粒度。有的人会写一个非常big的controller，用这个controller来控制N个页面（汗一个）。有人会为每一个页面产生一个controller，结果controller泛滥。有人不知道controller是干嘛的于是什么代码都往里面写，什么权限验证、数据验证、页面跳转、页面数据设置、业务逻辑、事物控制、数据库连接都往里面放！（好像有的东西的确应该往里面放）。

也就是说在使用controller的情况下，几乎很难把controller设计得很好，当然有人可以设计得很好，但既然不是大多数人，那么我有理由说controller的技术是有缺陷的。其实产生这一问题的原因很简单，controller是联系表示与业务的纽带，也就通讯员。通讯员该干什么，干多少，很容易搞混淆啊。哦，上面说的是struts的controller，webwork和spring的要好一些，struts的controller还不好单元测试（历史原因历史原因）

总结一下，MVC模式中的C存在的问题：

1.通常需要配置，比较麻烦

2.设计的粒度不会控制

3.该干什么事情容易搞错

4.部分controller难以单元测试

有这些问题自然要想一想，如果没有controller，行不行？

答案是这样的，在有了Ajax之后，controller终于可以不要了！

目前我使用的Ajax框架是DWR，通过使用DWR，controller的确是彻底去掉了。

怎么去掉的？我其实也没有刻意为之，只是DWR的工作模式本来就是这样的。。。DWR可以让客户端的Javascript直接访问远程的一个Java对象。也就是说表示层直接访问业务层。但是慢着，这并没有带来耦合。表示还是那个表示，业务还是那个业务，女人还是那个女人，狗还是。。。

我实在想不出使用DWR的情况下有什么理由要设计一个controller。

啊，好像还真有那么一点情况，客户端不支持Javascript。。。这种情况下，老实的搞MVC吧，但是不支持Ajax的浏览器挺少的。

还有吗？啊好像还有一个问题。如果想在业务方法中，访问session，request等对象如何办呢？比如要做一个购物车，购物车存放在session里面。这个问题吗？没有难住我，你可以存到数据库里面啊！啊！啊！不要扔臭鸡蛋！好了，好了我告诉你我有一个设计方法可以很好的解决这个问题，不仅不会在业务层嵌入任何与Web相关的对象，而且表示还是表示，业务还是业务，女人还是女人，狗还是。。。没有一点杂交的。但是这里的纸太小了，我写不下（偷偷说一句，其实不难啊）

也许有人提出MV模式实际还是MVC的，比如DWR就配置了一个servlet，这个servlet其实就是C

这要看你如何看待这个问题了。其实任何模式最后都是010101，因此任何模式实际都是一个模式。。。

为什么提出MV模式，我认为主要是为大家提供一种设计思路，MV模式的确带来了一些不同于MVC模式的思维方式。其实MV和MVC也不是矛盾的，大家灵活应用就是了。

最后，今后我们是不是可以多一个术语MV模式呢？