从JSF和Ext看WebUI开发－－给对JavaScript 有恐惧感的朋友

leebai

浏览: 63344 次
性别:
来自: 北京

最近访客更多访客>>

liutsi

博主相关

博客

微博

相册

留言

关于我

文章分类

全部博客 (8)

社区版块

存档分类

EXT JSF JavaScript UI Ajax

把其中我的观点整理出来：

100％支持fins！！！ B端和S端彻底分开，分别有自己的框架，“UI层与系统其他层面的东西的唯一联系应该是"数据" ，UI层应该是在后台系统不变的情况下可切换的”，这种架构策略完全可行，而且实际代码上也比JSF/asp.net等“server page”变种优雅，本人已经在N个项目中实践过：

http://www.xjawa.org/xjawa/kontent/10020.html

使用这个7wxAop框架（浏览器端7wx + 服务器端Aop），有个朋友喜欢用Ext做前端，他就把7wx替换成Ext，照样跑得很好：

http://www.deepsoft.com.cn/ext-aop/demo.html

那些不理解fins得同学，可能是没做过ajax开发，或者ajax用的比较少，或者思想已经被“server page ”方式禁锢。虽然本质上 jsf 还是“server page”，但确实比jsp、tag强很多；但是比起B/S完全分开得架构，jsf还是很丑陋。我们公司有个项目组用得是SAP得WebDynpro，和jsf类似，要比jsf成熟，但实际开发起来也是很多问题。

个人认为，fins设想的这种架构之所以未被普遍关注，是因为它损害了J2ee大厂商的商业利益，因此他们控制的主流IT媒体不愿宣传。想想：如果Server只是用来接受数据->处理逻辑->返回数据，服务器端将非常Lightweight和Performance，大厂商的J2EE服务器还有高性能硬件还会有几个项目需要？

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

。。。正如我前面提到的，不理解fins的人大多是思想被“server pages”禁锢者，总认为浏览器只能负责 html render，其他一切都应该在服务器上完成，就如IT业早期的主机－字符终端模式。这种思想本质上是把浏览器看作21世纪的字符终端，完全忽略和闲置了目前运行浏览器pc的强大计算功能。

。。。在一个server和UI无关的模式下（下面称为“server business”，与“server pages”对应），server只是一个business logic server（只接受UI请求改变或查询系统的state），大致相当于砍掉了J2EE的Web层，Lightweight是肯定的了，至于Performance，除了节省处理
'UI layer'(NOT ONLY 'presentation layer') 的CPU开销，更重要的是大量节省服务器的出口带宽开销。

。。。“server business”模式(SB)与“server pages”模式(SP)本质上是不同的,SP下的'presentation layer'概念并不适合SB模式。

。。。将ajax单纯地视为transition technology本身也没什么错，虽然Ext等前端组件已经超越了这一概念。用Javascript framework称呼基于浏览器的“全功能UI Layer"并不适当，后者 = HTML + DHTML(DOM) + JS，JS只是一个粘合剂，Ext等前端组件本质上只是扩展了HTML Element，假设HTML 6.0包含了功能强大的TreeView、ListView(GRID)等通用UI组件，则JS将回归为单纯的DHTML API操纵语言。至于RIA(javaFx or Flex)，我认为它是侧重多媒体表现的“全功能UI Layer"的等价物，它的发展前景取决于厂商对它的定位，如果你认同RIA，就没有理由不认同“全功能UI Layer"的思路。

JSF：基于服务器端的UI模型，Ext:基于浏览器端的UI模型。

很多人质疑以JavaScript为中心的UI开发，其实是对html/JavaScript的恐惧。

1、不要把《 HTML(含CSS) + DHTML（或DOM）API + JavaScript开发》简单理解成 JavaScript 开发。很多人觉得“JavaScript”难以掌握，是因为他们混淆了JavaScript脚本语言本身和它所要操纵的API：其实JavaScript本身非常简单，但它所要操纵的API“非常复杂”，因为HTML(含CSS) + DHTML（或DOM）API所涉及的API对象、属性、方法、事件数量巨大，可以说和Win32 API,JDK API（不单是swing/awt）同一个数量级。

2、HTML(含CSS)作为UI的表达语言，其“潜在的”界面表达能力应该说远远超越任何已有高端UI组件库（asp.net，jsf，Ext...）,因为它们本身都是基于HTML(含CSS)开发的，要想完整地（还不含绘图）、无障碍表达WebUI，掌握HTML(含CSS)及其API--DHTML（或DOM）是必由之路。

3、所有高端UI组件库的设计思想都是提高组件粒度，以掩盖HTML(含css)的复杂性。不同在于，服务器端UI组件（asp.net，jsf）试图“彻底”掩盖，它们排斥直接使用HTML(含css)，并且操纵UI组件的API面向后端语言（C#,VB,java）；而浏览器端UI组件（Ext等）是“开放性的”封装，允许直接操作HTML(含css)，操纵UI组件的API面向javascript。

4、服务器端UI组件的使用者，一般不太关心组件的具体实现，而且使用中也缺乏HTML+JS的训练，当组件功能满足不了要求时，自己扩展组件的难度很大，也就时说使用组件和开发组件之间存在巨大鸿沟。而浏览器端UI组件的使用者，一般会大致了解组件的实现，使用中频繁接触HTML，JS操纵能力也得到训练，因此他们会比较自然地形成组件改造扩展能力，使用组件和扩展组件之间得学习曲线是平滑的。

5、因此，从开发人员自身职业发展的角度看，要想成为无障碍的Web开发者，使用浏览器端UI组件模式应该是更好的选择。

作为Web开发者，必须热情拥抱HTML（css）和javascript，否则只能是半拉子开发人员。

分享到：

一个不会Struts，Spring，Hibernate，JSF ... | 一个简单的JSON-ext，对很常见的列表数据， ...

2008-04-23 12:09
浏览 5400
评论(174)
论坛回复 / 浏览 (171 / 74901)
查看更多

34 楼 leebai 2008-04-27

hax 写道

leebai 写道

同意“Server business”中，business logic层不能直接暴露给客户端调用（js其实也不可能直接调用Java），你说的那个Fasade层，我原先也将其称作是Controler，但这样容易与MVC的概念混淆，所以现在倾向于这样表述：
[size=small;]Ajax +“Server business”应用，就是View Controler
[size=small;]而你说的那个Fasade层，其实大有文章，远比MVC的Controler[/size]内容丰富，本质上就是V/M框架，虽然7wxAop框架已经实现了V/M之间的很多控制，目前我还没找到合适的词来表达它，这方面可以深入探讨。
[/size]+ Model应用，不存在

我感觉，大家得先定义一下这个Facade也好，Controller也好，它的具体职责是什么，和前后两端是如何配合的。否则很难说大家指的是一个相同的东西。

暂且称它为 X层吧（这个字母还真有桥梁、联接、中介的意思:-)）。

在7wxAop的Aop中，X层做了以下工作（比较乱，先随便列出来）：

1、临时停止和恢复business访问，某些后台维护时要用。
2、对model层掩盖multipart/form-data访问（既俗称的文件上传）和普通访问的区别
3、抽取Request各种信息，记入系统设置的一个数据结构，用于系统调试和排错。
4、在线用户列表维护
5、SSO机制支持
6、错误处理
7、访问日志处理
8、business方法的访问权限控制
9、指定并动态切换Model的数据源，DB连接及释放，事务管理
10、将Model层得到的业务数据封装成前端需要的格式，并返回
11、攻击检测及访问拒绝（实现了一小部分）
12、后台桩线程，用于每日，每周，每月，每年要做的定时处理

计划要在 X 中做的还有：
1、返回数据缓存策略
2、可配置、前端可指定的返回数据格式

有兴趣的同学，可以想想 X层还要包括哪些功能。

33 楼 hax 2008-04-27

leebai 写道

组件是王道没错，但模板在很多时候能解决组件无法解决的问题，尤其是界面显示的可定制性。举个例子：

7wx的ListView组件主要用于显示各种各样带翻页或不带翻页的内容条目列表，比如：

所有这些都是ListView组件Render出来的，界面中每个条目能显示成什么样子，是通过HTML模版定义的，你想象，单纯的OO Grid组件模式要显示这些形式各异的列表有多困难，这也是7wx ListView与其他js Grid完全不同的地方。

我没看过代码，我胡乱猜测一下，大概是这样？

var myList = new ListView(data, template);

container.addComponent(myList);

然后data是一个json数组，每行一个对象，对象中包含对象数据，比如每个都有filed1和field2。这就好象数据表一样。

template是某种格式的模板？比如xslt？或者自定义的html模板语言，比方说：
<li class="xxxList">
<div>${field1}</div>
<div>${field2}</div>
...
</li>

不知道是不是我猜测的那样？

32 楼 hax 2008-04-27

leebai 写道

同意“Server business”中，business logic层不能直接暴露给客户端调用（js其实也不可能直接调用Java），你说的那个Fasade层，我原先也将其称作是Controler，但这样容易与MVC的概念混淆，所以现在倾向于这样表述：
[size=small;]Ajax +“Server business”应用，就是View [/size]+ Model应用，不存在Controler
[size=small;]而你说的那个Fasade层，其实大有文章，远比MVC的Controler[/size]内容丰富，本质上就是V/M框架，虽然7wxAop框架已经实现了V/M之间的很多控制，目前我还没找到合适的词来表达它，这方面可以深入探讨。

我感觉，大家得先定义一下这个Facade也好，Controller也好，它的具体职责是什么，和前后两端是如何配合的。否则很难说大家指的是一个相同的东西。

31 楼 leebai 2008-04-27

<div class='quote_title'>hax 写道</div>
<div class='quote_div'>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>其实你这jCT中的“存储”型模板，完全可以被7WX框架借用（7WX中也有类似的东西，只是功能没jCT强）。Browser UI模型的“局部界面更新”，除了主流的“组件方式”外，确实还应该包含“模版方式”。</div>
 虽然我没有看过jCT和7WX，不过先放个空炮。上次jindw说他要搞客户端模板，我就跟他聊说客户端模板没啥前途，或者说存在一些与服务器端模板类似的问题无法解决。 模板（template）的主要问题是它是一种代码生成方式，因此与最终运行时模型是不匹配的。因此模板虽然有利于方便、安全的生成重复的代码，但是编写运行时脚本时的复杂度却大大上升了。我个人认为native的B端组件（data binding）才是王道，呵呵。 </div>
 组件是王道没错，但模板在很多时候能解决组件无法解决的问题，尤其是界面显示的可定制性。举个例子： 7wx的ListView组件主要用于显示各种各样带翻页或不带翻页的内容条目列表，比如：
 <img src='../../../../../../topics/download/274064eb-e7ac-3d06-8c7e-cdc7ee6cda42' height='938' alt='7wx ListView 演示' width='750'/>
 
所有这些都是ListView组件Render出来的，界面中每个条目能显示成什么样子，是通过HTML模版定义的，你想象，单纯的OO Grid组件模式要显示这些形式各异的列表有多困难，这也是7wx ListView与其他js Grid完全不同的地方。

30 楼 hax 2008-04-27

icewubin 写道

leebai 写道

在正真的B-UI应用中，Browser自己负责界面构造和界面跳转，Server只负责提供business logic 访问，也就是说[size=small; color: #ff0000;]Server上根本就不需要S-UI的Web层（虽然还是HTTP访问），没有所谓的Controler，也就是说MVC不再是真理，Spring MVC/Struts之类的Web层框架完全没有必要[/size]。“server pages”开发者理解B-UI时最大的思路陷阱就是“Web层”，MVC。 B-UI（Ext等界面组件+HTML+JS+ajax）是S-UI(jsp,jsf,asp,asp.net)的完全等价物，不存在什么功能jsf能做， B-UI不能做的问题。

从结构上来说，即使没有Controller层，business logic层不能直接暴露给客户端调用（由此我反对使用DWR框架），也就是说，还是要有一层Fasade，所以还是留着好，虽然名字还叫Controller但是主要职责已经变了。为什么说主要职责，是因为Controller层还是有它的用的，传统的方式比如自定义tag用来“写”（生成）JS的local数据要比发Ajax请求效率要高得多，应用场景是界面上的下拉框不需要频繁从服务端取数据，大多数情况都是取一次的，就没必要用Ajax请求。

或者这么说吧，如果页面上有10个下拉框，而且内容都不能写死，都要从服务端取，纯粹的Ajax方案在这种场景下性能反而是倒退的，因为http请求发得太多了。目前觉得还是结合传统的方式更好一点，可以一个ftl（或jsp）+一个JS文件，ftl（或jsp）中的代码可以很少，比如都是些取数据的tag。进可以完全的不用tag语法，退可以随时大量用传统语法解决变态需求。

并不能说DWR框架就一定导致business logic暴露给客户端。使用Facade和DWR并不矛盾啊。而且我认为Controller如果仅仅是为了解决网络存取效率问题，那并不能算是Facade，只能算一个Proxy。而且如果考虑HTTP支持keep-alive和pipeline的话，可能就不必考虑多个请求的问题了，那样的话又如何？——注意我并非说B端可以直接操控biz logic，但至少你这里的理由不充分。

29 楼 icewubin 2008-04-27

hax 写道

leebai 写道

其实你这jCT中的“存储”型模板，完全可以被7WX框架借用（7WX中也有类似的东西，只是功能没jCT强）。Browser UI模型的“局部界面更新”，除了主流的“组件方式”外，确实还应该包含“模版方式”。

虽然我没有看过jCT和7WX，不过先放个空炮。上次jindw说他要搞客户端模板，我就跟他聊说客户端模板没啥前途，或者说存在一些与服务器端模板类似的问题无法解决。

模板（template）的主要问题是它是一种代码生成方式，因此与最终运行时模型是不匹配的。因此模板虽然有利于方便、安全的生成重复的代码，但是编写运行时脚本时的复杂度却大大上升了。我个人认为native的B端组件（data binding）才是王道，呵呵。

支持。

28 楼 leebai 2008-04-27

to icewubin:

有需要的话可以给我发站内短信，不过事先声明：

流行的Struts，Spring，Hibernate，JSF，XMLHttpRequest,prototype，Ext，IOC，Tag lib，jquery，rest，EJB，SOA，dojo(估计可以列出50个名词)。。。我都不会用，请不要问，呵呵；

我只会：Java，Servlet API，JSP懂一点，SQL/JDBC，HTTP协议， HTML/CSS，DHTML/DOM，Javascript这么几个基本的东西。底层的东西基本上难不倒我。

27 楼 hax 2008-04-27

leebai 写道

26 楼 icewubin 2008-04-27

leebai 写道

hax 写道

探讨很有意思，不知道楼上几位都在什么地方，如果能找机会聚在一起互相介绍一下各自的框架和经验，就更好了。

确实有直接交流的必要，好像你们上海和阿拉北京的人相对多些，其他地区的网友比较散。

我是上海的，现在确实碰到一些问题，无法通过现有交流渠道听听别人的见解，我的部门经理现在不管具体的技术实现了，技术细节无法找人论证，又不能动不动就拿实际项目做实验，这个问题越来越严重了。

25 楼 leebai 2008-04-27

hax 写道

探讨很有意思，不知道楼上几位都在什么地方，如果能找机会聚在一起互相介绍一下各自的框架和经验，就更好了。

确实有直接交流的必要，好像你们上海和阿拉北京的人相对多些，其他地区的网友比较散。

24 楼 hax 2008-04-27

探讨很有意思，不知道楼上几位都在什么地方，如果能找机会聚在一起互相介绍一下各自的框架和经验，就更好了。

23 楼 leebai 2008-04-27

<div class='quote_title'>JJYAO 写道</div>
<div class='quote_div'>我大致看了下楼主自己开发的web框架，可以说是典型的JavaScript based的web框架。与几年前在市场上做的比较好的dorado类似。典型的特征是在客户端有一套相对比较丰富的JS UI组件和DataBinding机制 首先肯定一下楼主的框架，XJawa具备以上特征，应该说也确实能够实现一定范围内的快速开发。但单纯从技术上看Xjawa，我觉得还有几点值得探讨 1. 客户端的对象类型都是Javascript数组（是否意味着在客户端模型的基本仍然停留在JavaScript低层语言级别，开发人员还需要掌握JavaScript语法）。另外，这套框架应该开放了大量的JS接口，这套接口学习的成本不低。所谓几个小时的培训恐怕～～ 2. 从该框架在服务端需要编写WebActions的子类可以看出，离所谓的纯粹的B和S还有点距离（WebActions子类完全不是业务方法，方法参数居然还是HttpServletRequest），这个比较好的实现楼主可参考DWR和Seam的实现 3. 楼主自行开发了大量的UI组件，这些组件应该是纯粹的JS控件。JS控件的缺点就是随着需求增加，控件的复杂度不断提高，最终可能会使得控件难以发展和维护 4. XJawa是否属于one page one application?如果不是，现在如何处理页面的navigation? 5. 其他问题，客户端的性能，是否延迟加载等等 6. 其他的由于业务复杂度导致的问题(多是导致页面动态性，比如通过某种复杂的条件导致页面大面积动态变化或替换XJawa是否能胜任)? 从楼主实现的框架和帖子来看，有少许对服务端技术的偏见。这点我也可以理解。我的建议是多比较比较客户端技术和服务端技术在整体和局部上的细节差异和优缺点，是不是真的如自己想象的那样。比如楼主一再强调的 
<div class='quote_title'>引用</div>
<div class='quote_div'>在正真的B-UI应用中，Browser自己负责界面构造和界面跳转，Server只负责提供business logic 访问，也就是说Server上根本就不需要S-UI的Web层（虽然还是HTTP访问），没有所谓的Controler，也就是说MVC不再是真理，Spring MVC/Struts之类的Web层框架完全没有必要。 </div>
 其实在你的框架里并没有真正实现，而目前服务端技术其实已经完好的实现了.从我以往的经验，不要过分将自己东西绑死在某一种方式或者技术上可能更有利于框架的发展</div>
 喜欢和你这样认真细致的人讨论问题。 
 
不能在短时间内理解7wxAop不是你的问题，一方面大家对“Server business”模式还比较陌生，另外7wxAop的文档也欠缺，希望通过讨论我能把它说清楚。 
 
7wxAop是一个精简的框架，客户端7wx封装的js代码大约是3000行，服务器端Aop封装的Java代码大约是8000多行，写最简洁的代码是我的编程原则，因此代码量可以看出工作份量：首先它是一个Web开发的总体框架，其次大头在“Server business”(Aop)，“JS based UI”(7wx)部分相对简单，当然从重要性来说两者相当。相比Ajax无刷新机制、Ext/dorado的丰富UI组件，7wxAop的侧重点是“Server business”编程支持，7wx倒是可以被其他组件替换。 
 
我确实不喜欢“Server Pages”用于业务应用,从servlet println() 到JSP、Tag、velocity、jsf。。。因为对强交互的业务应用来说，这种结构不合理。但对于CMS/BBS/BLOG/WIKI/社区/圈子...等等以信息服务为主的应用（不含这些东西的后台管理系统）来说，“Server Pages”是必然之选，“Server business”反而不适合，这一点我看得很清楚，基于7wxAop开发的Kontent CMS,其实信息服务部分就是“Server Pages”技术。 
 
关于你提的几点探讨，还是一条一条来： 
 
1、我个人喜欢用数组，我想老一点的程序员（用过Apple BASIC，或更老的）都喜欢用数组。能用数组简单完整的任务，为什么非要用Iterator或各种Collection结构？越简单的数据结构，系统开销越小，运行越快，越不容易有内存泄漏等难以排查的Bug。尤其是对于一个HTML页，其应用代码再复杂，能复杂到哪儿去，非得要用高端对象代码来提高程序可读性？另外我说过使用7wxAop需要一定的 js 基础（如主题所说，我认为不会JS的Web开发者是半拉子开发者），js的培训不算框架的培训，7wx远没有Ext复杂，所暴露的接口并不多，即便通读其3000多行代码，也用不了1天时间。所以7wxAop的学习开销你完全不用担心。
 
2、你的意思我明白：主流的分层模型教导我们，不要将Web层的东西传递到业务层，WebActions既然用了HttpServletRequest，WebActions就不是业务层了。我的观点是，如果你有独立的业务层（比如EJB），就把WebActions当成Web层好了；否则，7wxAop建议在WebActions中实现所有的Model功能，那么HttpServletRequest是否玷污了Model？如果存在Web层，则是；但7wxAop中不存在Web层，7wxAop的“Server Business”模式本身并不依赖于Web层的Servlet API，甚至也不需要HTTP协议的 full implementation ，这里使用HttpServletRequest而不是诸如ActionRequest的对象作为WebAction的参数，只是为了实现方便，也许在下一个版本的7wxAop，你就会看到一个ActionRequest（现有框架代码中的org.xjawa.system.DeepRequest类就是用于这个目的，只不过没实现，该类目前在框架中悬空没用）。所以，你说的“离所谓的纯粹的B和S还有点距离”是对的；另一方面，如果克服一下主流的分层模型教导我们的“洁癖”，以及根深根深蒂固的Web层观念，Model层使用一下HttpServletRequest也不是什么原则性的问题。
 
3、你的说法“政治上正确”。7wx的组件其实不是很多，和Ext等强调OO的UI组件不同，7wx组件采用HTML模版来作为组件显示元素，扩张相对容易。
 
4、不是。7wx在框架内部使用最简单的window.open跳转页面(不鼓励也不反对用户代码直接使用window.open)。
 
5、7wx很快，界面响应比Ext快的多。下载的系统已经有很多应用功能，你自己可以体会。分页是“延迟加载”，性能自己体会，7wx翻页允许最终用户自己改变每页行数，在确实需要浏览很多条目的情况下，比“预先加载”方式更有效。
 
6、使用7wxAop，业务复杂度的增长和系统复杂度的增长是线性的：在前端,增加业务只是HTML页面；在后端增加业务只是增加WebActions，不会有哪个XML文件或Java文件越滚越大。“页面动态性。。。”那段没看明白，能否具体点？

22 楼 icewubin 2008-04-27

JJYAO 写道

我大致看了下楼主自己开发的web框架，可以说是典型的JavaScript based的web框架。与几年前在市场上做的比较好的dorado类似。典型的特征是在客户端有一套相对比较丰富的JS UI组件和DataBinding机制

首先肯定一下楼主的框架，XJawa具备以上特征，应该说也确实能够实现一定范围内的快速开发。但单纯从技术上看Xjawa，我觉得还有几点值得探讨
1. 客户端的对象类型都是Javascript数组（是否意味着在客户端模型的基本仍然停留在JavaScript低层语言级别，开发人员还需要掌握JavaScript语法）。另外，这套框架应该开放了大量的JS接口，这套接口学习的成本不低。所谓几个小时的培训恐怕～～
2. 从该框架在服务端需要编写WebActions的子类可以看出，离所谓的纯粹的B和S还有点距离（WebActions子类完全不是业务方法，方法参数居然还是HttpServletRequest），这个比较好的实现楼主可参考DWR和Seam的实现
3. 楼主自行开发了大量的UI组件，这些组件应该是纯粹的JS控件。JS控件的缺点就是随着需求增加，控件的复杂度不断提高，最终可能会使得控件难以发展和维护
4. XJawa是否属于one page one application?如果不是，现在如何处理页面的navigation?
5. 其他问题，客户端的性能，是否延迟加载等等
6. 其他的由于业务复杂度导致的问题(多是导致页面动态性，比如通过某种复杂的条件导致页面大面积动态变化或替换XJawa是否能胜任)?

从楼主实现的框架和帖子来看，有少许对服务端技术的偏见。这点我也可以理解。我的建议是多比较比较客户端技术和服务端技术在整体和局部上的细节差异和优缺点，是不是真的如自己想象的那样。比如楼主一再强调的

引用

在正真的B-UI应用中，Browser自己负责界面构造和界面跳转，Server只负责提供business logic 访问，也就是说Server上根本就不需要S-UI的Web层（虽然还是HTTP访问），没有所谓的Controler，也就是说MVC不再是真理，Spring MVC/Struts之类的Web层框架完全没有必要。

其实在你的框架里并没有真正实现，而目前服务端技术其实已经完好的实现了.从我以往的经验，不要过分将自己东西绑死在某一种方式或者技术上可能更有利于框架的发展

听起来非常不错，我会好好构想的。

目前为止在想调试的时候会不会效率低下的问题，因为数据都挤在一起。

还有就是数据先集中再各自分发，自己要搞一个规模不小的框架，第一感觉就是投入很大啊，又没有现成的比较成熟的框架能搞定这个“数据岛”模式的？或者是系统性的介绍有没有啊？

21 楼 JJYAO 2008-04-27

引用

20 楼 leebai 2008-04-27

to taelons: 那个“很不谦虚”的回帖语气欠妥，在此自省一下:-)。 MVC是“Server Pages”模式的必然选择，所谓的MVC框架实际上只解决了Controler问题，M和V都要靠其他技术实现；如果抛弃“Server Pages”模式，Controler失去意义，那些MVC框架自然也就可以淘汰，Web层开发的混乱和低效的局面将会改变。 to icewubin: 
同意“Server business”中，business logic层不能直接暴露给客户端调用（js其实也不可能直接调用Java），你说的那个Fasade层，我原先也将其称作是Controler，但这样容易与MVC的概念混淆，所以现在倾向于这样表述：
Ajax +“Server business”应用，就是View + Model应用，不存在Controler
而你说的那个Fasade层，其实大有文章，远比MVC的Controler内容丰富，本质上就是V/M框架，虽然7wxAop框架已经实现了V/M之间的很多控制，目前我还没找到合适的词来表达它，这方面可以深入探讨。
至于你说的“10个下拉框”个例，完全可以不依赖"Server Pages"技术：如果10个字典之间是独立的，则一次Ajax请求返回10字典数据既可。如果10个字典之间是联动的，在新建初始化时，只获取第一个字典；在更新初始化时，根据各字典的当前值一次性获取各字典的相应字典数据；初始化后在用户改变选择时动态加载下级字典。多级联动的另一个替代输入方式是树型组件，后者很多时候更灵活。

19 楼 dboylx 2008-04-26

我有一朋友做的AJAX项目里有用到类似的东西,

称为"数据岛"模式,

还有，LZ的项目也类似,

很多种业务被一次请求, 同时服务多个业务组件.

但数据同时也可以很灵活的通过AJAX动态的响应客户的行为,

"数据岛" 用Observe向外抛出的事件注册接口,

各各组件只要把自己关心的部分并注册监听, ＵＩ组件不用关心数据何时与为何更新的数据，实现动态的响应客户的请求的一种小方法。

不过对于长年使用JSP,Struts,JSF的团队要转变方法与强大的思维惯性做斗争是更为麻烦的事情。

18 楼 icewubin 2008-04-26

dboylx 写道

icewubin 写道

或者这么说吧，如果页面上有10个下拉框，而且内容都不能写死，都要从服务端取，纯粹的Ajax方案在这种场景下性能反而是倒退的，因为http请求发得太多了。目前觉得还是结合传统的方式更好一点，可以一个ftl（或jsp）+一个JS文件，ftl（或jsp）中的代码可以很少，比如都是些取数据的tag。进可以完全的不用tag语法，退可以随时大量用传统语法解决变态需求。

一次请求获得多种数据, 分别把数据绑定在不同的 "数据消费者" 上.

你说的我也想过，但是没有深入，也没有看到过什么介绍，感觉自己冒然深入开发这个模块成本不低，主要是现有方式时间成本和时间成本非常低，所以暂时利用tag了。

顺便询问一句，又没有好的实践方法，能很方便（低开发时间成本）的把数据绑定在不同的“数据消费者”上呢？

17 楼 dboylx 2008-04-26

icewubin 写道

一次请求获得多种数据, 分别把数据绑定在不同的 "数据消费者" 上.

16 楼 icewubin 2008-04-26

leebai 写道

感觉楼上两位对 Browser base 的UI开发（下面简称B-UI,对应S-UI:jsp,jsf等Server base 的UI开发）所能达到的程度并不了解。

在正真的B-UI应用中，Browser自己负责界面构造和界面跳转，Server只负责提供business logic 访问，也就是说[size=small; color: #ff0000;]Server上根本就不需要S-UI的Web层（虽然还是HTTP访问），没有所谓的Controler，也就是说MVC不再是真理，Spring MVC/Struts之类的Web层框架完全没有必要[/size]。

“server pages”开发者理解B-UI时最大的思路陷阱就是“Web层”，MVC。

B-UI（Ext等界面组件+HTML+JS+ajax）是S-UI(jsp,jsf,asp,asp.net)的完全等价物，不存在什么功能jsf能做， B-UI不能做的问题。

jsf需要结合Ext、ajax，只能说明jsf实现某些功能很费劲，只好借用B-UI的现成技术。

保留MVC的空架子有时候是减少风险，万一碰到特别恶心的需求还有退路。

从结构上来说，即使没有Controller层，business logic层不能直接暴露给客户端调用（由此我反对使用DWR框架），也就是说，还是要有一层Fasade，所以还是留着好，虽然名字还叫Controller但是主要职责已经变了。为什么说主要职责，是因为Controller层还是有它的用的，传统的方式比如自定义tag用来“写”（生成）JS的local数据要比发Ajax请求效率要高得多，应用场景是界面上的下拉框不需要频繁从服务端取数据，大多数情况都是取一次的，就没必要用Ajax请求。

或者这么说吧，如果页面上有10个下拉框，而且内容都不能写死，都要从服务端取，纯粹的Ajax方案在这种场景下性能反而是倒退的，因为http请求发得太多了。目前觉得还是结合传统的方式更好一点，可以一个ftl（或jsp）+一个JS文件，ftl（或jsp）中的代码可以很少，比如都是些取数据的tag。进可以完全的不用tag语法，退可以随时大量用传统语法解决变态需求。

15 楼 taelons 2008-04-26

楼主果然很不谦虚啊，哈哈，你的方案我有空看看
个人觉得JSF用起来很费劲，在s做b端的事，如果想在s端封装b端的展现，就直接在b端用js算了，何必再增加网络流量。现在我做B-UI全部都是html和js，没有tag和<%%>用ext后就不需要struts来进行页面跳转了

spring以前从来没用过,struts用的一直是1.1的老版本。我所看到的一些开发团队，
虽然用到了spring/struts等框架，但开发过程中MVC这块还是一片混乱，很少看到代码框架清晰的案例。我个人比较排诉spring和最新的struts，估计新人的学习成本够呛

« 上一页 1 2 … 7 8 9 下一页 »

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论