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模式呢？

没有用户代码，不代表该框架角色不存在

这只是 event-driven 的 UI programming，早就有了。

我觉得 controller 的意义在于把分散的请求集中到一个通道中, 从而能透明的应用一些通用的 过滤/包装/预处理/后处理 逻辑, 达到重用这些逻辑的目的, 和AOP的思想和目标有些类似.

不用AJAX其实也能去掉 controller, 每个页面分别提交到不同 URL 就行了. AJAX 的结果是一个 "页面" 中天生可以有多个目标URL, 各自用途也不一样, 所以更容易让人想到指向不同的地址.

MV 模式，不是你的新玩意儿。。。那不就是Document 模式嘛。VB、ASP.net上比比皆是。

你的说法其实就是就是ajax让web更象VB罢鸟。

mv的说法肯定不是什么新玩意，现在又有几个计算机技术是新玩意？
在我以前的项目中我用其他手段也实现了和ajax一样的东西，按照这个说法ajax也不是什么新玩意。
也许是我没有说清楚，我的意思是：采用ajax开发网站，我们可以跳出原有的mvc的框框，采用mv的方式。而这种方式和GUI程序中model和view混杂在一起的编程方式也有不同。这种网站开发中的mv模式，它是松散耦合的，而GUI程序中的mv是紧密耦合的。
mv模式是我为了方便问题的说明下的一个定义，方便后文的引用。类似于“在下文中简称这种方式为MV”。


对于这个问题，我已经解释了，对于DWR等框架Controller是存在的。但对于我们使用框架的人来说，Controller是不存在的。就好比使用高级语言编程的人，从来不会考虑机器语言。谈论mvc模式的时候，也不会考虑图灵机模型。

我也只看了几天的ajax还没用到项目中有以下几点看法
1.本身ajax不是java专用技术（不用java也能实现）
2.ajax减少了页面的总量。。。（很多功能在同一个页面内完成）
3.ajax不包括在mvc架构中而是一种web的C/S的变型。。。。（如果加上DWR的话才像点MVC）
4.ajax提出了一种新的开发方式。。。（使学习css成为程序员必修课）

这种方式和GUI程序中model和view混杂在一起的编程方式也有不同。这种网站开发中的mv模式，它是松散耦合的，而GUI程序中的mv是紧密耦合的。 -----  什么叫混在一起？为什么就松耦合，为什么就是紧耦合？ 是不是自己的编程思想有问题？


你列举的情况恰恰说明MVC的回归。从Front Controller或者page controller回归到“古典/经典MVC"因为XMLHTTP成为了可能---客户端可以发出视图事件给控制器，同时可能可以接受模型改变事件。(只是可能）。

我觉得是其实没有改变mvc模式，只是不需要自己写controller了。