现在构造一个jsp应用，有两个设计思路：
一、在jsp页面中调用bean，bean负责数据库的连接，根据某些条件查询数据库并返回一个或者多个所查询的表的对象（自己封装的表的类），然后bean再生成一个HTML表格形式的描述该数据内容的表格，并当作一个String类型返回给jsp，jsp再显示该表格。
二、jsp调用bean，bean根据程序条件返回给jsp一个或者多个所查询的表的对象，jsp根据该对象构造显示的方式。
使用一的理由：表格的格式比较固定，而且如果在其它页面要使用同样形式的表格则不用再在jsp页面中重新构造，而只需要调用bean中的对应方法；缺点是页面不够灵活，HTML制作者不能控制数据的显示格式。
使用二的理由：灵活，但是在重用时需要拷贝，增加工作量。
本人趋向于使用第一种方式，请说出您的看法，并给出您的理由！更欢迎其它方案！
如果精彩意见很多，我将再增加本帖子的分数。

Hi,
目前我们采用的基本是第二种方式. 我觉得有很问题, 做jsp的非常辛苦, 做bean的也不见得多轻松 ... 不知道你们的项目/产品是否存在很多一个bean(我指能反应业务逻辑的bean)同若干个jsp页面关系紧密? 我有个想法, 但目前还没实现:p 我打算借助一定格式(schema约束)的xml来描述其中的关系, 并希望能通过某种类似向导的形式生成bean和对应的jsp页面(可能也不需要jsp页面, 但至少要有个template, 那时xmlc会派上用场) ... 我想这样处理的将是一个功能块, 并且bean和jsp页面可以打成一个包括发布到某一平台上 ... 当然, 这不可能满足所有情况, 但我认为我所接触的项目中至少有80%的情况可以这样处理 ...
我又说梦话乐, hehehe ...

我的想法同你的有一点不一样:p
我是用一个bean完成查询等共同的操作(支持多表), 而其它(项目需要做的)bean则只是指明需要操作的对象. 这个方法我已经应用在一个项目中, 开发起来很快, 效率也不比以往的差, 而且目前看来还比较稳定^^

在我看来，用Bean作为中间层，而仅使用JSP来作结果的显示是一种更好的方法。
很明显，这样会减少jsp的工作量，而且结构更好合理，以后的维护时，只需要修改Bean

另外再给你一个思路：
还是用bean来取数据库，封装成一个表的类，到这里都与你的方案一样。bean本身不处理数据的显示。在显示输出上用自定义标签的方法来简化jsp的制作.

呵呵 ... 正是如此 :)
只不过在此基础上进行了额外(必要)的包装. 至于你提到的tableName, fieldName等, 可以用一个对象包装起来 ... 不知道这些对象包含的信息在你那里对相应jsp页面的表述有极大的帮助? 至少在我这里是有很大帮助的:p 所以我才会有前面的生成jsp页面的想法, 其实就是以此作为依据之一, 不知你是否觉得合理? 有时候我想, 这样应付中小的项目或许已经够了(乱猜:p), 如果一定要用application server, 那么考虑将那个common bean转成ejb是否也是可行呢? 我觉得j2ee很好, 看了j2ee vs .net的文章更觉得受到鼓舞, 但我不会为此不管实际需求给客户一个做成ejb的*简单*的聊天室 ... 我觉得自己现在想得挺简单(这样不烦, hehehe), 目前只期望完成能协助完成快速开发并且能比较稳定的平台, 至于速度, 我想不会比我走路慢 :)

对了, cherami, 不知你是否有兴趣做一个类似的平台?

当然要采用第二种方法，第一种方法要写bean的人把Html也要定下来，试问这有什么可操作性呢？采用第二种方法相比有很多的优势，写bean的人可以传回你想要的东西就可以了，比如用一个Vector 封装了的prop，或者直接就是prop数组，都可以，然而我认为其他的一切的想使其更简单的、想封装它的东西都不能真正的使它简单起来，最好的还是再加一层servlet，或javabean来实现业务逻辑，使逻辑和数据库的使用分开。

返回的数据类型不同，怎么做成一个通用的javabean.
返回的数据怎么处理最方便(vector，数组，还是直接resultset?)
请各位发言？