版主是否给来点Structs和持久层开发的东西学学啊？

lummyliao · 发表于 2004-12-6 20:19:52

现在越来越多的网站采用JSP,Servlet, 那么如何快速，方便，有效的开发
JSP网站成为一个关键的因素，采用一个功能强劲，使用方便的工具(Framework)相当重要，有SUN做后盾的Jakarta就是这样的一面旗帜
Jakarta的众多的优秀产品已经深入人心,
Web Server -- Tomcat
JSP Framework - Struts
Servlet Framework - Turbine
基于XML的编译环境 - Ant
Log 工具 -- Log4J
Mail Enterprise Server - James
Components Framework - Avalon

OK,言归正传:

JSP Framework - Struts

Struts将 Presentation 和 Business Logic分离开来
写页面的人只须了解如何使用Struts提供的TagLib库
写业务的逻辑的人把业务逻辑写在Struts配置文件中.
Struts提供FormBean和ActionBean,以及业务的逻辑定义(XML配置文件)
也就是说你把所有的业务逻辑定义写成XML文件
定义你的FormBean,JSP page的逻辑走向，ActionBean的入口.
所有的后台操作（操作数据库或与EJB交互)写在ActionBean里.
所以一定要正确描述XML配置文件的业务逻辑,光有JSP Page和
ActionBean Class File是跑不起来的.

Structs 通过一种 Pattern 叫 Model-View-Controller (MVC)
如果您开发过大型 Web 应用程序，您就理解变化这个词的含义。“模型-视图-控制器”(MVC) 就是用来帮助您控制变化的一种设计模式。MVC 减弱了业务逻辑接口和数据接口之间的耦合。Struts 是一种 MVC 实现，它将 Servlet 2.2 和 JSP 1.1 标记（属于 J2EE 规范）用作实现的一部分。尽管您可能永远不会用 Struts 实现一个系统，但了解一下 Struts 或许使您能将其中的一些思想用于您以后的 Servlet 的 JSP 实现中。

这里有一篇IBM介绍Struts的文章，非常优秀
中文
http://www-900.ibm.com/developerWor...uts/index.shtml
英文
http://www-106.ibm.com/developerwor...brary/j-struts/

Struts还可以和JBuilder,Weblogic整和在一起调试开发,

JBuilder 5, Struts 1.0 & WebLogic 6.0, a Tutorial
http://www.netstore.ch/mesi/strutsTutorial/

http://www-106.ibm.com/developerwor...brary/j-struts/

1.要写好的JSP
会写JSP并不代表你的JSP是好的，什么是好的JSP？看一些“best practices”可以帮助你。

http://www.javaworld.com/javaworld/...-1130-jsp.html?
JSP best practices
Follow these tips for reusable and easily maintainable JavaServer Pages

---

2.适当的使用模式
模式用来描述所交流的问题及其解决的方法，在J2EE的表示层有哪些模式可以使用呢？
请参看《J2EE 核心模式》中的的第七章

---

3.适当的使用一些工具
比如说：Structs。

Structs的大本营，里面有好多好东西，自己慢慢翻吧。
http://jakarta.apache.org/struts/index.html

yangyi81 · 发表于 2004-12-7 09:44:05

版主给仔细讲讲Hibernate吧，以前只是皮毛的看了一点东西，留下的一点印象只是不用手动创建数据库了，全写在配置文件里面，比较有趣，呵呵。但是对持久层还是没什么概念。

lummyliao · 发表于 2004-12-8 09:42:32

一、Hibernate是JDBC的轻量级的对象封装，它是一个独立的对象持久层框架，和App Server，和EJB没有什么必然的联系。Hibernate可以用在任何JDBC可以使用的场合，例如Java应用程序的数据库访问代码，DAO接口的实现类，甚至可以是BMP里面的访问数据库的代码。从这个意义上来说，Hibernate和EB不是一个范畴的东西，也不存在非此即彼的关系。

二、Hibernate是一个和JDBC密切关联的框架，所以Hibernate的兼容性和JDBC驱动，和数据库都有一定的关系，但是和使用它的Java程序，和App Server没有任何关系，也不存在兼容性问题。

三、Hibernate不能用来直接和Entity Bean做对比，只有放在整个J2EE项目的框架中才能比较。并且即使是放在软件整体框架中来看，Hibernate也是做为JDBC的替代者出现的，而不是Entity Bean的替代者出现的，让我再列一次我已经列n次的框架结构：

传统的架构：
1) Session Bean <-> Entity Bean <-> DB
为了解决性能障碍的替代架构：
2) Session Bean <-> DAO <-> JDBC <-> DB
使用Hibernate来提高上面架构的开发效率的架构：
3) Session Bean <-> DAO <-> Hibernate <-> DB

就上面3个架构来分析：
1、内存消耗：采用JDBC的架构2无疑是最省内存的，Hibernate的架构3次之，EB的架构1最差。

2、运行效率：如果JDBC的代码写的非常优化，那么JDBC架构运行效率最高，但是实际项目中，这一点几乎做不到，这需要程序员非常精通JDBC，运用Batch语句，调整PreapredStatement的Batch Size和Fetch Size等参数，以及在必要的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行效率。EB的架构效率会差的很远。

3、开发效率：在有JBuilder的支持下以及简单的项目，EB架构开发效率最高，JDBC次之，Hibernate最差。但是在大的项目，特别是持久层关系映射很复杂的情况下，Hibernate效率高的惊人，JDBC次之，而EB架构很可能会失败。

4、分布式，安全检查，集群，负载均衡的支持
由于有SB做为Facade，3个架构没有区别。

四、EB和Hibernate学习难度在哪里？

EB的难度在哪里？不在复杂的XML配置文件上，而在于EB运用稍微不慎，就有严重的性能障碍。所以难在你需要学习很多EJB设计模式来避开性能问题，需要学习App Server和EB的配置来优化EB的运行效率。做EB的开发工作，程序员的大部分精力都被放到了EB的性能问题上了，反而没有更多的精力关注本身就主要投入精力去考虑的对象持久层的设计上来。

Hibernate难在哪里？不在Hibernate本身的复杂，实际上Hibernate非常的简单，难在Hibernate太灵活了。

当你用EB来实现持久层的时候，你会发现EB实在是太笨拙了，笨拙到你根本没有什么可以选择的余地，所以你根本就不用花费精力去设计方案，去平衡方案的好坏，去费脑筋考虑选择哪个方案，因为只有唯一的方案摆在你面前，你只能这么做，没得选择。

Hibernate相反，它太灵活了，相同的问题，你至少可以设计出十几种方案来解决，所以特别的犯难，究竟用这个，还是用那个呢？这些方案之间到底有什么区别呢？他们的运行原理有什么不同？运行效率哪个比较好？光是主键生成，就有七八种方案供你选择，你为难不为难？集合属性可以用Set，可以用List，还可以用Bag，到底哪个效率高，你为难不为难？查询可以用iterator，可以用list，哪个好，有什么区别？你为难不为难？复合主键你可以直接在hbm里面配置，也可以自定义CustomerType，哪种比较好些？你为难不为难？对于一个表，你可以选择单一映射一个对象，也可以映射成父子对象，还可以映射成两个1:1的对象，在什么情况下用哪种方案比较好，你为难不为难？

这个列表可以一直开列下去，直到你不想再看下去为止。当你面前摆着无数的眼花缭乱的方案的时候，你会觉得幸福呢？还是悲哀呢？如果你是一个负责的程序员，那么你一定会仔细研究每种方案的区别，每种方案的效率，每种方案的适用场合，你会觉得你已经陷入进去拔不出来了。如果是用EB，你第一秒种就已经做出了决定，根本没得选择，比如说集合属性，你只能用Collection，如果是Hibernate，你会在Bag，List和Set之间来回犹豫不决，甚至搞不清楚的话，程序都没有办法写。