【讨论】关于彻底的MVC的随想

:arrow:  
   在项目开发中一个偶然的思考，突然让我想到了一个问题。那就是MVC的划分，常用的MVC架构像struts, webwork, JSF, spring MVC等等，其实已经很多了，但是感觉其实都没有摆脱b/s架构的束缚。因为MVC中的V按理说指的就是视图层，而在一个企业级应用中，视图层的确应该不限于web浏览器。而先前接触到的各种mvc框架似乎都没有提供这样一种功能，让我在不改动服务端逻辑的前提下更换视图层（比如把web浏览器更换为桌面应用客户端）。其实想想，这样的需求并不像发射个炮弹去撞彗星那样无用。尤其在现在移动终端普及的年代。举个曾经遇到过的个问题。当初在做手机wap游戏的时候就曾经考虑过，能不能把服务做成通用的，用户既可以通过wap（wap浏览器，bs结构）来访问这个应用，也可以通过kjava或者brew客户端应用来访问这个游戏。因为当时没有考虑的很深，最终还是放弃了。因为当初选用的struts MVC框架，要求用户的访问入口是Action，那么和用户的交互也就严重耦合到了httpRequest和httpResponse对象上，这样就断送了kjava和brew程序访问这个应用的可能。

       然而这次突然的灵感让我想到了这样的问题，既然那么多框架都是为了解藕，为什么就不能把MVC的V和MC的耦合解的彻底一点呢。我觉得基于现在的已有技术应该是可以实现这一点的。比如，我们的服务端应用都部署为webservice（burlap和hessian的效率好像还是很高的），这样就没有了对客户端强制要求（也就是对request和response的类型的强制限制）。传统的客户端调用webservice自然是没有问题的，那么就是在bs框架下，我们也要通过webservice而不是传统的http request & http response来访问服务端应用，似乎是一个问题。

       带着这个问题，我上网搜索，发现了的确有人和我考虑着同样的问题，并且提出了一种通过javascript来访问webservice的可能。其实bs只不过是统一客户端（浏览器）的cs，和cs并没有本质的区别，而javascript正是深度发掘了这个统一客户端所有功能的工具。这么说来，bs和cs就几乎完全一样了。没有了传统的直接操作http request & http response的服务端应用，那么服务端和客户端之间传递的都是java对象（无论是cs还是bs下），那按照这个逻辑框架，理论上就可以使V和MC彻底解藕，开发的服务端就可以通用于浏览器或者客户端程序，在这个逻辑下制作的MVC框架才是彻底的MVC。

       不过，写这样的js和自定义整个流程中间的规范（也就是开发这个彻底的MVC框架），代价还是很大的，我还没有找到现成的成熟的实现。如果哪位达人正好知道的话，请不吝告知，拜谢拉:D

JSF不是依赖桌面系统浏览器的 webwork同理。

那jsf或者webwork下的应用怎么实现用桌面客户端访问呢

wow,这个idea早就有了
可惜浏览器技术始终都很烂。
javascript和webservice调用协议怎么说？

现在IBM和BEA鼓吹的SOA好像就是这个意思。

不管什么M，C。最后暴露给V的都是Web Service

不管是什么样子的V，都是通过Web Service和后面的层打交道。

看了一些这方面文章，觉得理论上不错。
特别是如果有了一个很好的基础框架，类库之类的话。开发起来应该不错：）

不过目前似乎还不太到火候吧：）如楼主所说，目前还没有这种完善的框架。而且如果真的完全变成Web Service来通信，交流。肯定还有一些麻烦或者没有想过的地方，确实都是风险。

不是这么简单的，核心问题还是智能的转移。传统的 J2EE Web 层框架中的 MVC 架构都是基于 Thin Client 模型的。一个基本的假设是智能完全存在于服务器端，并没有考虑到客户端的处理能力。Ajax/Flash/XUL/XAML 还有移动智能应用的出现使得智能客户端越来越流行，客户端的智能有越来越强的趋势。这个趋势对于传统的 MVC 架构形成了很大的冲击，传统的架构如果不重新思考和设计，就很难适应这种变化。首先遇到的问题就是服务器端的 Controller 无法控制客户端的表示逻辑，而不能简单地把分布在客户端的表示逻辑作为原来架构的 View 来看待。现在不仅服务器端要有 MVC，客户端同样要有 MVC，并且它们之间还要进行交互和同步。因此需要以一种新的角度，综合考虑客户端和服务器端智能的分布，设计出来一种新型的整体 MVC 架构来。
Ajax in Action 这本书的核心内容是关于设计模式的，特别是 MVC 模式，里面关于这些内容讨论的很多，感兴趣的话可以看看。

解耦的核心问题是通讯协议。

对于这样的应用层面解耦来说，其实是很大程度是选用技术的解藕——业务设计层面的解藕是依赖的解藕。让适当的技术负责它最擅长的工作，尽可能的不要涉足其他技术领域。

对于view来说，以表模式获得数据就已经足够了，view的逻辑就是操作数据表以及将action发送到controller。对于控制业务逻辑的controller来说（java程序），最好的形式就是普通的java对象，就像以command模式实现的xwork.

对于web程序来说，buffalo就是我要找的东西。我是从swingchen的ess框架中，才知道了buffalo——俺孤陋寡闻啊，不过作者的宣传似乎做的也不够。

“Buffalo中定义了Web远程调用的传输基础，并且将远程调用对象完整的序列化到了本地，成为可以被JavaScript编程触及的对象。”
这样view层就相当彻底的脱离出来，页面上只有了html和javascript.
而swingchen则是想结合jsvm将js的组件化。

另外有个wicket是原来sun搞swing的那帮人整出来的，号称能干净的分离view层，可以使用多种视图技术，支持不同的客户端，比如 HTML、Flash/Flex、Swing，但那种page object的写法，我一直都不怎么感冒，也没细看了。

啊，啊，刚看到gmail邮件列表里buffalo作者mechiland的一段对话：
mechiland: 实际上，buffalo鼓励三种方式的使用：
第一种，最纯粹的远程调用需求，可以嵌入到任何一个页面中就是buffalo 1.0的雏形
mechiland: 第二种，整合现有的web应用，例如Struts,webwork已经写好的
然后利用buffalo.switchView来进行切换
这样可以得到服务器端与客户端的双重好处
buffalo.switchView以后会加入缓存机制，这样就不必每次读取而已有的应用往往将大量的计算操作已经完成。通过buffalo的集成，实现了较好的向Ajax应用的迁移

第三种，全部使用buffalo, 这只限于小型应用。
在buffalo后面的版本中，会加入一个小型的页面切换框架仅仅支持页面转发而不是MVC, 所有的业务逻辑都会在浏览器段完成buffalo托管所有的一切。但是限于浏览器的能力，这种方式只限于页面数量较少，例如邮件客户端，聊天室等应用程序


我的想法，近似于第二种吧。