如何建立自己的O/R Map?

如果是大量查询的东东，还是建议使用 DB Store Procedure 或直接使用 SQL。
使用对象来完成 heavy loaded query，是不好的选择

我现在还只是在选择一个方案,这只是我的毕业设计,我想尝试一下用OOP的方式来做,各位能提点意见吗?

存储过程和预定义SQL我以前用delphi的时侯做过,取来数据后,客户端还得对数据再加工抽出有用的信息,也就是客户端得了解数据结构,不可避免地将界面和逻辑混在一起了

>>存储过程和预定义SQL我以前用delphi的时侯做过,取来数据后,客户端
>>还得对数据再加工抽出有用的信息,也就是客户端得了解数据结构,不可
>>避免地将界面和逻辑混在一起了

也许，你需要建一个由DAO(Data Access Object) 和 VO(ValueObject) 构成的数据层.

这样对于视图逻辑，数据是经过封装的，不需要知道底层数据的存储结构，只通过 VO 和 DAO 的接口，就可以进行 CRUD(Create, Read, Update, Delete) 操作

谢谢iceant!你的指点让我找到了一个方向.
我现在初步的方案是:
后台用关系数据库,用servlet控制分派,javabeans封装数据库操作,jsp页面处理
如果直接使用SQL,那么jsp进行页面处理时,还是和以前用ASP时一样,我一直在寻找一个合适的数据层,以我的理解javabeans还是算在jsp这一层,所以我的设想仍是Servlet/JSP的结构,只是组织上清晰一点
我应该怎么去调整这个结构呢?一个成熟的Web应用一般是采用什么结构的呢?
我的目标是做到界面与逻辑尽可能地分离开来,数据结构与业务逻辑尽可能地分离开来

一般书上都是直接用JDBC了事,但我的感觉是JDBC只是一个单纯的数据存取引擎,只是负责连接,传送SQL,返回结果集,不可能也不应该将它设计的太过复杂,所以仅仅依靠JDBC来作为数据层功能上太单薄了一点,我的想法对吗?

>一个成熟的Web应用一般是采用什么结构的呢?

这个问题可以写一篇论文或一本书。
从简单的入手。 大概是两年前， JSP/Servlet 的两种编程模型被广为流传。也就是 Module1 和 Module2 的编程方法。
Module1 使用 JSP + JavaBean 完成系统，JSP 负责 View 展现，JavaBean 负责逻辑数据处理。
Module2 使用 Servlet 做分发器，系统只有一个入口。
按请求的不同 Servlet 会分发给不同的 JSP 来响应。

经过一段时间的发展， MVC 模式被用于 WEB 系统的构建，一开始是 PetStore 的 Demo, 然后是 Struts, JATO..... 越来越多的框架被开发出来。

PetStore 可以说是教学的好典范，但是不适合大系统的构建，以前我怀疑这一点，也用它开发过一些系统，但是开发起来很麻烦。

Struts 没有用过，只是当初在通读 Code 的时候，拿来读过一些，具体的系统结构我都没有懂清楚，不好评说。只留下了一个滥用 taglib 的印象。

今年开始接触和研究 JATO, 设计得非常好，印象最深的，就是它的事件模型和 taglib 的妙用。但是它独有的 Model 带了移植上的一些麻烦，如果有一天你不再使用 jato, 那可能要小心照顾这些 Model. 当然，它也支持 JavaBean 做 Model. 只要稍花点心思去设计一下各层的接口，仍然可以做到非常灵活。

不知道你现在的水平如何，如果对 J2EE 的基本结构和产品线搞清楚了，可以去看看 J2EE Core Design pattern 和设计模式(Design pattern)
对你理解上面的这些框架很有好处。

另，如果想学习学得快一点，就去参加一个 OpenSource 的项目。
最好是国外的，它们的管理和开发模式要正规一些。

如果对 EJB Container 感兴趣可以看看 OpenEJB 的设计和代码，相对于 JBOSS 来说，它小得多，而且从设计上来说，是很好的~

使用O/R Map　JDO或者Castor比较合适。

如果是"客户端连上来的数量一多,每个都查询不同性质的数据,"
就使用DAO模式，适合大量查询数据。

如果你需要"从数据库读取　反复的创建对象"，那么就要再细分你的业务，根据情况在上面两个之间选择

非常感谢两位的指点,我知道该怎么做了

请问怎么获得Castor JDO呢?

上有个ftp://ftp.exolab.org/pub/castor/castor_0.9.4.1/castor-0.9.4.1.jar
但我在教育网里,就算用代理也下载不了

终于下载到了...

考虑了一段时间后,我初步的做法是这样:
在J2EE架构中,数据是通过使用ValueObject模式在各层中传递,而数据访问则是使用DAO模式,这两个模式共同构建了数据访问层,数据访问层与业务层之间通过ValueObject联系起来.

我觉得这个ValueObject如何设计与DAO的设计是联系在一起的,我现在试图建立的数据访问层是基于独立的主键生成策略,采用定制集合的方式,返回的仅仅是主键的一个collection,只有当客户调用了read方法后才真正的读取相应的数据.

我之所以这样做是因为我找不到比较好的O/R Map方法,只好自己手工做,因此我的DAO使用了template模式,自己写SQL,完成O/R Map. 因为我不打算用EJB和JDO,而是只用JDBC.

我大概地分析了一下,这种做法的性能瓶颈在于连接池的大小和性能,因为所有的操作都是迅速释放连接的,相对于数据处理过程,取得连接代价更为昂贵.
缺点也很明显,就是要频繁的连接数据库,虽然时间短但并发问题没有彻底解决,只是减小了发生的几率.

我现在正为事务和并发这两个老问题伤脑筋,按理事务是不应在数据访问层解决,数据访问层应该是连接数据库的底层事务处理与业务层的商业事务处理.另外还得自己写SQL,不够OO,不够自动化.

大家能给点意见吗?