B/S展现层的选型探讨

B/S展现层的选型--抛砖引玉

背景
传统的应用程序体系在客户端运行业务逻辑并提供丰富的GUI图形界面。同时，GUI界面上很多供应商提供了丰富的WYSIWYG(所见即所得)的开发工具，比如Delphi,VC,JBuilder等等。随着n tie体系结构的提出，业务逻辑集中的概念，组件的概念逐渐深入人心。于是越来越多的技术人员投奔于n tie。业务逻辑集中的确给程序的发布和维护带来了很大的方便。 但问题也随之而来：

1、客户抱怨界面太过于简单且不够好用。很多功能诸如参照、智能化输入、多窗口等等因为基于request的b/s结构。烦恼的不断刷新，烦恼的刷新实现。
2、报表系统不是太慢就是太过于简单，同样存在不友好的问题。报表工具我该用什么？复杂的实现？
3、设计上来看，由程序员去设计HTML页面确实不符合社会分工的原则。，老天，WYSIWYG，dreamweaver我只会用一点，photoshop我根本不会用。
4、展现层上存在业务逻辑的结果是代码不复用。 混乱混乱，我的中间层怎么成了SQL执行器？
5、javascript以及css，说道，真挺令人厌烦的。 javascript?怎么浏览器换成Mozilla就不能用了？烦恼。
6、如何让我们的展现层和做类或者组件那么简单呢？面向对象？我这到处代码嵌入的jsp页面，是不是面向对象programm？

。。。。。。。。。。。

简单一句话， Struts可以解决你说的展现层所有问题。真的不骗你。

struts不能解决所有问题，呵呵

至少，struts不能解决错误提示在focus离开的时候就显示给用户
比如，只能输入数字是最简单的，这还是javascript

的确，楼主说的n-tier的问题的确是存在，我们也一直在苦恼这个问题，最头大的是边界多了，tier多了，处理起来更加麻烦了，查个错也要满地找牙

晕4，看清我的文章。 是rich thin-client。 我要的是GUI界面，不是html.

Struts很很不好玩，去年我用struts做过一个项目后，从此彻底放弃了。

好坏？ 简单，struts是面向过程的，struts是不可视化的。还不如用jsp.

大胆设想：
为了可以WYSIWYG地设计GUI，直接用IDE，如delphi设计，然后做一个XMLGenerator根据form文本文件生成XML。
发布一个客户端，客户端访问服务端的时候，返回界面分布的XML，然后客户端根据XML画出GUI。

to zzeric:
你的设想不算大胆了，以前就做过一个，叫做thick　client的，用户用起来确实很爽，GUI没得说，但开发起来很麻烦，除了分两端开发，还有XML的传输，数据加密，一大堆问题，尤其是最后的integration测试，很痛苦

to weihello

你说的这个，昨天的tss也有几个相关的产品发布介绍，你可以翻翻看。既然你说的是b/s结构， 还是要用html的。

struts就是个mvc框架， 估计你还不会用呢。

用自定义标签，可以不用struts就达到struts对view的功能。
不过标签要好好设计。

weihello说的B/S结构并不是单纯指Browser/Server结构，而是相对于C/S结构而言的，使用类似于B/S的n层结构，但又可以拥有C/S程序那么丰富的GUI。

>>简单一句话， Struts可以解决你说的展现层所有问题。真的不骗你。
简单一句话,banq你可真土，真的不骗你。

> 晕4，看清我的文章。 是rich thin-client。
> ?我要的是GUI界面，不是html.

那你就继续研究吧～，我的客户好像对于如此新的东西不感冒，我自己也没有把握把整个系统结构移植过去，还能受得住系统压力... ...~

对了，我不反对GUI，只是觉得，html还是未来，呵呵～
实现某些东西麻烦一点，但是给使用者很多方便，还是值得的

其实老实讲句，我觉得某位支持Struts的

只是一个普通级别的人物而已，

从其回贴的内容，语句描述等就可以看得出来

讲的东西都不会是详细的，一个可能是其自己不身也不是很懂

一个可能就是真的是牛人（我感觉不出来，你感觉出来了吗？)

我见过的有个东东，它可以将 Swing 写的程序直接放到 WEB 服务器上运行，而不需要改代码。

其实它就是在WEB层加入了对 Swing 控件的支持，利用 HTML 做控件的绘制。另外，开发者还写了JavaScript来模仿 Swing 中的事件。像是在 WEB Container 里模拟了一个 Swing 的 Container.

不过，这样的东东是否能承担大的访问量，我就不太清楚了。

下页