随着prototype DWR 等ajax框架的流行,
服务器端生成js代码返回客户端,由客户端调用(直接调用或eval)似乎已经成为了一种很正常的做法(是否流行我不知道).
这种做法(其实是一种设计)本身无可厚非,但是常常被人错误的理解和应用
(此处所谓的"错误"是基于我的立场,也许更多的人会认为我的观点才是错的 呵呵).
用过DWR的人都知道,实际上DWR传给客户端的JS并不是包含了很复杂的业务逻辑和表现逻辑,他只不过是向客户端发送了一些信息,
这些信息告诉了客户端如何调用服务端暴露出的服务.这些信息本质上只是一些数据,确切的说只是一些参数.
DWR实现的web remoting,只是对下面这种做法的一个变种.
ajax.request("service对应的url","service需要的参数","service调用结束后要做的事情")
DWR传过来的JS,实际上的只是扮演着"service对应的url","service需要的参数","service调用结束后要做的事情"这些参数所扮演的角色.
对于真正的业务逻辑还是包含在服务端的service里.
所以我不止一次的说过"没什么事情是必须要用DWR那种方式来做,而用prototype + servlet做不了或是做起来很困难的".
因为两者都能够做到而且也都正做着同样的事情.
但是DWR的这种做法有时候会产生一些不良暗示:服务端生成js供客户端调用是一件很不错的事.
甚至容易让人把这种做法和JSF的事件机制混为一谈.
于是通过ajax请求返回的信息变得丰富多彩.其中最可怕的就是返回复杂的HTML和JS脚本.
现在还有一种可怕的事情是 客户端提交js脚本,服务端用rhnio运行
(我曾就就做过这种可怕的事 呵呵,但是那个系统尤其客观性,不过其实完全可以避免的,只是当时懒了).
在一个ajax的请求与响应中,服务端与客户端交互的信息应该只是作为数据载体的字符串(xml json序列等).
这些数据会告诉对方要去做什么 以及为对方提供必要的参数,而不应该包含告诉对方怎么做.
传递js语句也可以,但是这些js语句一定要是能够和json划等号的,任何夹杂了 if for = 等操作的js都是应该极力避免的.
在服务器端生成HTML的做法实在是为了照顾羸弱的浏览器而做出的让步,其实这种做法本身完全是个错误,
不过在相当长一段时间内,我们还将继续错下去.
当然我这里说的完全是ajax相关的东西,JSP、tag不在讨论范畴之内,
但我还是要补充一句: 我虽然曾大量是使用和开发tag,但我对它是非常厌恶的,
使用上也许还比较愉快,但是开发起来真够恶心的.我讨厌一切在服务器端生成html代码的行为.
关于tag这是另外一个很大的话题了,以前在javaeye上的相关讨论并不少,在这里就不再多废话了.
好了,现在该说些和标题有关的东西了(晕).
我先问几个问题:
当你要整合两个分别使用 j2ee 和 php 编写的系统时,
当你要在一个j2ee系统中使用php系统中的一部分功能时,
当你要从一个j2ee系统向另一个.net系统中传递数据时,
你会怎么做?
会变态的用java重写另外一个系统?
会更变态的将j2ee系统用php/.net重写吗?
会用j2ee生成php/.net可以理解的代码,让对方运行吗?
不会的,你首先想到的会是WS,会是MQ,会是REST,会是SOA.....
其实服务端 与 客户端 就是两个独立的系统,而且是两个独立的异构系统.
处理他们之间的关系和处理两个大型的异构系统的关系非常类似,应该咬住"服务"二字不放.
所谓"服务"应该是: 生产者提供,消费者享用.
而不是: 你告诉我我每一步要怎样做,然后我再一步步的做给你看. 这不叫服务,这叫"奴役".
任何企图在一端生成另一端代码的做法都是欠妥当的.
因为世上没有B/S系统,只有B系统和S系统.
多说一句,GWT如果设计成是在运行期生成最终html/js代码的,那么他将是愚蠢的,幸好他们没那么,但是现在的他离愚蠢也不远.
这篇文章同样比较凌乱,也不知道我说明白我想说的没.
其实我只是想告诉大家(主要是新手),应该站在服务的角度来看待系统的层次和结构,
每一层只是向其他层提供服务,并享用其他人的服务,而无权干涩别人提供的服务的细节,也不应该让别人干涉自己.
有了这样的认识,如何传递数据,如何做到系统层次件的解耦就是很自然的事情了.
当然本着"世事没有绝对,凡事都有例外"的原则,我这些观点不适用于所有系统.
以上观点只代表我个人看法(当然有一些观点不是我首创),欢迎大家提出反对意见
.