Struct-Spring-Hibernate
这些架构的产生是由于当时的技术应用存在问题，例如Session Bean移植难，开发难，需要继承很多类，且在容器中运行，难以Debug; EJB2是一个大而全的架构，用于真正的分布式应用，否则效率很差。而将这些技术改良而产生的，或为了提高编程工作效率，提高重用（例如Hibernate）；相对提高运行效率；解决复杂业务环境中的横切面代码复用问题（例如Spring）；或现实世界中面对多变的需求需要修改代码而代码又需要健壮的问题（例如Spring）。而这些新产生出来的架构又较多的使用了一些设计模式，例如Struct使用了Command, Hibernate使用了Factory等。
对于应用规划中的技术选择，一般以满足用户需求为目标；但也充分评估非功能性需求，例如扩展性（过度考虑，配置文件会多，系统难安装）、稳定性、可维护性等，对系统设计的影响；分离系统中变与不变的部分；并采用分层的架构构建系统，以便于替换，也可以同时开发，单独测试。
Hibernate:
Hibernate用于构建持久层，对比于JDBC：
1，在原来JDBC的编程中，用得较多的是四段式：建立Connection, Statement，返回resultSet, CloseConnection. 而Hibernate就把这些封装了起来。所以说是提高了工作效率和可维护性；
2，并且容易加入Cache工具，可对内存存取，而JDBC写死SQL，每次都到DB中拿。相对来说有更好的性能，但是如果业务逻辑是每次都有新的内容要存取，效率就会低了，因为做了封装的缘故
3，且有方言特性，移植到另外DB相对于JDBC来说比较容易，但也麻烦（how?）
Hibernate适用于联机事务处理，增删改查。不适用于BI，数据挖掘，大量数据的报表生成，由于其SQL复杂，缓存命中率低，所以效率低。
实现的时候，将对象模型（实体类）对应于XML配置文件（映射文件，自动生成），XML又对应于表结构。采用SessionFactory（整个应用只有一个）提供公共类，在多个应用线程中共享，不需要考虑多线程和冲突问题，但不是线程安全的，代表着与数据库的一次操作。
关于持久化对象的状态和作用是什么？瞬态，持久化状态，脱管状态？
实体关系的处理......
事务管理机制......
Struct
MVC框架，核心功能
1，前端拦截器（AOP实现策略），用于数据验证、中文处理等
2，运行时表达式验证
3，类型转换
4，强大的表达式语言（对象图浏览语言OGNL）
5，IOC容器
6，支持多种视图表达
7，支持AJAX
Struct实现
Action一次请求, Result一次结果定义, Inceptor动态拦截Action调用的对象
(未完代续)
对于应用规划中的技术选择，一般以满足用户需求为目标；但也充分评估非功能性需求，例如扩展性（过度考虑，配置文件会多，系统难安装）、稳定性、可维护性等，对系统设计的影响；分离系统中变与不变的部分；并采用分层的架构构建系统，以便于替换，也可以同时开发，单独测试。
Hibernate:
Hibernate用于构建持久层，对比于JDBC：
1，在原来JDBC的编程中，用得较多的是四段式：建立Connection, Statement，返回resultSet, CloseConnection. 而Hibernate就把这些封装了起来。所以说是提高了工作效率和可维护性；
2，并且容易加入Cache工具，可对内存存取，而JDBC写死SQL，每次都到DB中拿。相对来说有更好的性能，但是如果业务逻辑是每次都有新的内容要存取，效率就会低了，因为做了封装的缘故
3，且有方言特性，移植到另外DB相对于JDBC来说比较容易，但也麻烦（how?）
Hibernate适用于联机事务处理，增删改查。不适用于BI，数据挖掘，大量数据的报表生成，由于其SQL复杂，缓存命中率低，所以效率低。
实现的时候，将对象模型（实体类）对应于XML配置文件（映射文件，自动生成），XML又对应于表结构。采用SessionFactory（整个应用只有一个）提供公共类，在多个应用线程中共享，不需要考虑多线程和冲突问题，但不是线程安全的，代表着与数据库的一次操作。
关于持久化对象的状态和作用是什么？瞬态，持久化状态，脱管状态？
实体关系的处理......
事务管理机制......
Struct
MVC框架，核心功能
1，前端拦截器（AOP实现策略），用于数据验证、中文处理等
2，运行时表达式验证
3，类型转换
4，强大的表达式语言（对象图浏览语言OGNL）
5，IOC容器
6，支持多种视图表达
7，支持AJAX
Struct实现
Action一次请求, Result一次结果定义, Inceptor动态拦截Action调用的对象
(未完代续)
