从实际开发中得出的一个假想----JS版的MVC

对于交互的体会致使个人尝试将表现层逻辑与业务层彻底分离，具体来说：
由JS来负责所有的表示层逻辑，服务器端只负责业务逻辑
基于实际的需要，在开发过程当中使用了DWR来负责完成远程调用，用TrimPath Template来简化显示逻辑的处理，即便如此我还是体会到不少麻烦：
从发出远程调用到获得模型数据，并基于此的流程控制逻辑再到UI更新整个流程重复出现在每次的调用里
以及代码组织上的混乱，还有其他一些只能意会不能言表的痛苦

最后得出的结论是：表示层逻辑从服务器端转移到客户端之后并没有对这些逻辑的实现提出一个很好架构方案，在服务器端的时候我们有WebWork,Struts，但是到了客户端却没有这样的MVC，这里的高手们，你们觉得有这种需求吗：一个基于JS的MVC的实现，同时完成远程调用的封装？

呵呵，恰好前两天也在思考这个方案，感觉有前途。
quake以前提过，写了demo，可是现在下不到了
本来ajax与传统的服务器端技术在功能上就有重叠，我有点怀疑webwork与某些ajax技术集成，会舍弃（或不推荐使用）自身的哪些东西。
用dwr，少不了写一堆callback。而典型的CRUD，就应该像ruby on rails的scaffold一样，看起来用js写这种框架十分有意义，起码避免写callback，放上点类似webwork的chain result一类的。另外，trimpath.com上的Junction号称是ruby on rails用trimpath等技术的另一种实现，我大致看了一下，没有找到它用了哪个ajax技术，而它在客户端生套rails的实现（从形式上），也不大喜欢。玩过的朋友讲讲课吧。
另外，trimpath的JST如何像tapestry一样（俺不懂:) ），进行组件、模板重用，也是很有意思的事，出于能力，想不明白 

你说的Junction我略看了一下，因为我也是希望能找到轮子而不是自己发明轮子，不过那个MVC做了不该做的事情（个人觉得），他在服务器端和客户端同时提供基础结构，服务器端的基础结构完成CRUD的代理，然后你通过JS编写业务逻辑和CRUD操作，很有创意，不过绝对不敢用，而trimpath的JST则仅仅是类似velocity的模板技术，只不过是用JS实现的而已，可以通过Ajax取得模板文件由trimpath template解析生成HTML，这样省却了HTML的构造工作也使得structure和数据分离开来

Swato 0.72版中重新整理了一下前台的程序，将HTML与JavaScript控制程序
彻底分开。http://59.137.211.248:8080/swato

对于页面的模版，也单独分离出.jst文件，由Ajax方式读入后进行解析执行。
(放弃了原来来自trimpath的库，自己写了一个更轻量级的基于JS语法的一个引擎)->
http://swik.net/SWATO/Swato+JavaScript+Template

to zigzag_chen:自上次你介绍了自己的框架后，我略看了一下Quickstart，发现了一个让人不大舒服的设计，提供简化远程调用的支持的同时带来了对服务器端组件的侵入，而且客户端的js代码我觉得也远不如DWR好用，所以我觉得在远程调用的封装上DWR远胜一筹。但是你的想法也是非常给我启示的，就是实际上客户端代码没有得到根本性的简化，所以那之后我慢慢开始着手做这样一个框架，集成了DWR的远程调用能力以及TrimPath的template功能，加上自己实现的表现层的流程控制逻辑，使的具体开发时尽可能只需编写action单元和jst文件，对于细粒度的DOM更新则提供工具函数来辅助完成简化工作。

to kuky:
我不知道你实际对DWR的了解和认识有多少，DWR对服务器端的组件是完全无侵入，同时能够映射成JS对象，完全不存在什么加上服务层。当然我的想法的实现是基于DWR的一个集成。

个人感觉基于jason或是dwr这类的Js透明调用Java方法并不是一种很好的client端和server端的解决方案，它们毕竟不是一种类型的语言，在它们之间应该有一个平滑的过度结构才对。

我最近正在研究，很感兴趣，谁能告诉我DWR文档的PDF格式的下载地址是多少？我找不到，

DWR的学习成本还是比较低的，特别是对于我这个不怎么懂javascript、css以及xmlHTTP的底层开发人员而已，感觉如鱼得水，我对页面层的技术没怎么研究，只会做简单的html，但实际开发又不得不接触复杂的页面技术。

呵呵，我倒是对spring rich client很感兴趣，记得你以前专门发过这方面的帖子，怎么最近兴趣转移了？