一个初步设想，麻烦高手看看可行性

[gameboy766]

目前有个初步设想，当然也很有可能已经有人想到了，甚至实现了，这样的话更希望有经验的朋友来谈谈。

我想实现这样一个结构：

UI部分：纯html+js+css，所有的UI逻辑统一由js控制
服务端：通过webservice处理所有业务，并提供业务的webserice接口供客户端调用
传输： ajax
即 UI <==>ajax<==>webservice

这样做的好处，我能想到有：
1、UI部分逻辑统一，便于控制
2、webservice可重用性高
3、借助现有的js库（如yui等）界面较为美观

不足的地方目前我就是觉得js部分开发难度较大，请问，除了这个问题，这样做还有什么比较严重的缺陷或问题？或者我所谓的优点里面也有不太现实的地方？

另外，我也没见过有类似的网站，总感觉可行性不高:(

[gameboy766]

另外补充下，这个设想主要针对较复杂的web应用程序（特别是界面逻辑），一般的网站当然没有这样做的价值

[metaphy]

服务端：通过webservice处理所有业务，并提供业务的webserice接口供客户端调用
=====================================
网站有这么做的嘛？
做大型企业应用还差不多

webservice主要解决远程或分布或异构体系的问题，用来做网站有点大炮打蚊子的感觉

[gameboy766]

恩，我补充里面也说了的，就是主要针对复杂的web应用，普通网站肯定毫无意义

[gameboy766]

初步设想是使用SOAP 标头来处理安全验证等问题，而且也主要用于企业内部应用

楼上这位朋友能具体谈谈有那些安全问题么？

[kingbox731]

安全性是个大问题

[tslearn]

1) javascript 效率太低
2）Dom 有的游览器支持的太差

[masse]

jquery,extJs,prototype,yahoo-ui不都实现了吗，
只是server端这四个框架都没限制，
你反而要限制一下，不太可行

如果你的应用要用到，可以在这几个项目上加以改造。
ajax框架
http://www.jopener.cn/category/ajax-frameworks/
富客户端组件
http://www.jopener.cn/category/rich-client-tools/

[秋色之美]

方案出来的效果会不错，有一点比较难解决的是安全问题，我做过企业内部应用的，应用效果很好，就是安全性存在隐患。

[gameboy766]

恩，只要是纯技术讨论，并注意语气，大家应该都不会发火的:)

ASP.Net的服务器控件个人认为优势就是快速开发，劣势当然就是楼上说的那样，尽管有ajax.net，但如果只是用uploadpanel的话，根本是治标不治本，对此有疑问的朋友可以自己截取http包来看看，webcast上我记得也有提uploadpanel的问题，反正要想达到最优化的效果，还是得自己手写js-_-。

这里举个例子吧，一个button点击后引发服务端事件执行一段业务逻辑，成功界面某个Label显示成功提示，失败显示失败原因。如果是Asp.Net服务器控件这种操作方式，拖两个控件，双击button写上业务逻辑代码即可，开发速度一个字，快，而如果是其他开发，除了业务逻辑外，一定要自己写一堆request、response之类的吧（我没实际搞过java，也许很方便吧）。但为了防止用户有意或无意的多次点击，一般这个button点击后就会立即禁止，而这个操作就只能是前台js的事情了，这样就造成了我上面说过的禁止button和显示Label，这两个都属于UI部分的逻辑，却分别在前台js和后台cs里面（虽然也可以在后台注册js代码，但我认为那样更加麻烦，原因后述），维护上势必造成很多麻烦，当然这个例子很简单，但实际情况中往往会有很多复杂的UI操作，这时确实很麻烦。另一个较严重的问题是，因为UI的变化较业务逻辑而言，有时候更频繁，如果是在后台cs里面写UI逻辑（比如例子中的设置Label的显示内容，或者注册js代码之类），那么当有变化时，往往需要重新编译cs，然后更新，特别是对于需要7x24的项目，这肯定是不允许的，而如果将UI逻辑彻底分离到html或js里面，因为是静态的，所以更新方便，对运行中的项目也几乎无任何影响，当然“缺点”就是开发速度肯定不如“拖控件”快。

另外，搞Asp.net的朋友，如果在UI逻辑处理上有其他建议或方式，也欢迎提出，我这个设想也就当是一块破砖吧，希望能引出美玉来^_^

再另外，Asp.net如果不用服务器控件以及aspx文件，而采用ashx文件的话（其实就是IHttpHandle），我觉得大体上和jsp、php也就没啥区别了，说白都是 请求－响应（当然细节上就不用扯了，肯定各有各的做法）。如果我不用webservice的话，也就准备采用这种方式了，也请对ashx有研究的朋友谈谈经验或这样做的问题。

[gameboy766]

谢谢楼上的朋友，其实我就是在看了yui等之后才有的这个想法，如果真要搞，也肯定会选择一款（暂定yui^_^）。

而你所说的“限制”是指的WebService么？其实我也觉得不一定非要WebService，只是如果是WebService的话，将来重用起来方便些，比如遇见B/S改成C/S的情况，至少服务端就可以直接用WebService了。

另外，这几天，我也在进一步看这些js框架，感觉使用他们的还是搞jsp和php的居多，其实我拿不定主意的主要原因是我是asp.net环境-_-。而之所以想到不用服务端控件，而摆弄纯html，主要是因为考虑到应用UI的复杂性，如果使用标准aspx页面，使用服务端控件，往往需要将UI逻辑分散在前台js（比如一些操作提示或立即性的操作效果显示）和后台cs里面（如数据绑定或界面元素的变化等），总感觉不是滋味，而像yui这类方式，可将UI逻辑清晰的放在js部分，而后台（当然可以不是webservice）只需专心负责业务逻辑即可，即UI逻辑和业务逻辑的分离。但又想到jsp也“模仿”asp.net也搞了个jsf出来（搞java的朋友不要生气，这里只是让搞asp.net的朋友容易理解些而已），而我还“倒退”到html，感觉也不是滋味，所以很矛盾。

[chaircat]

说对了...JSF就是模仿的!
别发火,我还没说完...
ASP.NET本身的架构就不好,还学它...
事件驱动,却要以刷新界面为代价...
简直不伦不类...要知道页面状态会随之reset...
象autocamplete这样的东西就几乎没法实现...
本来,如果IE是基于.NET架构之上的,脚本也是运行在CLR之上就可以通过Remoting解决...
可是...大家都看到,即使MS有这个打算短期也不会实现...
所以...我们继续搞C/S...C就是浏览器...
严格区分客户端服务端...
表老想着服务端怎么弄的...

PS...玩java的兄弟自己把上面的.NET技术对应过去...一样的...

[xuStanly]

关于这个，本人也在采取这种模式开发。

http://www.speedsoftech.com/test/list4man.htm?class=mine
这里有个用来测试效率的页面，采取的就是
前台（HTML）--》AJAX--》后台（ASP）--》存储过程--》数据库
的结构。

好处：
前后台完全分开，组队开发时，美工，程序员，数据库管理员可以各行其事，
灵活度大，前台页面可以根据不同的浏览器开发不同版本，而后台只要输出的XML文件格式正确，
不管其后台是JSP、ASP、.NET还是PHP，都可以被前台页面调用。

缺点：
这种模式首次应用，尚不成熟，进度较慢

[chaircat]

呵呵~~~的确是这样...
这种模式还需要慢慢锤炼...

[gameboy766]

恩
目前对于我来说也还只是纸上谈兵 ，只结合YUI做了个简单的例子。初步看还不错，在YUI的支持下，客户端这边的代码也不算多而且很清晰，服务器这边暂时用的asxh，数据传输格式用的JSON。

[sf0223cn]

学习了~

[jyk1970]

UI <--->ajax<--->webservice

UI部分：纯html+js+css，所有的UI逻辑统一由js控制

传输： ajax

服务端：通过webservice处理所有业务，并提供业务的webserice接口供客户端调用

我大概明白搂主的意思！
另外请问服务端仅用servlet和普通java类，可行否？

[gameboy766]

webservice只是初步的设想，只是希望进一步提高服务端的重用性，但如果没这方面要求，那么就没必要用webservice了，其实我测试就只是使用了.net里面的ashx，即IHttpHandler，如果楼上的没接触过asp.net，可以把这个简单想象为就是java里面的servlet。而且从目前查看的资料看，这在java方面倒是较常见的富客户端方式，所以楼上说的应该是可行的。而我举棋不定主要原因在于是否放弃asp.net本来的快捷开发方式，所以最近抽空再多做几个例子感受感受。

[netharry]

当然可以，Asp.net Ajax就支持这种模式。

[visulcer]

我也想这样做。原来大家也都在想这些东西。看来我要重新考虑，想一些更新的设计了。

现在的JavaScript真是越来越疯狂了。

[gameboy766]

恩，因为最近较忙了，过段时间再进一步研究，所以就先把分给大家结了吧