2.4.2 开发技术
2.4.2.1 Struts
2.4.2.1.1 选用理由
Struts是最成熟的基于MVC架构的J2EE前台开发架构，底层是采用Servlet开发的。使用人多，技术讨论最多，文档齐全。开发工具支持最好，主流和非主流的开发工具都有支持，特别是IBM WSAD （eclipse）和Jbuilder的支持就更完善了，可以看到页面工作流的图形显示。
采用Struts架构可以分工开发。按前台和后台开发，可以估算工作量，有多少页面和多少业务逻辑要做，M （模型），V（视图），C（控制）。三者可以分工合作开发。采用struts还有就是它的可扩展性非常强，可以扩展新的技术如velocity，tapestry ，sun的JSF，xml，xslt等技术，是个非常开放性的工具。
2.4.2.1.2 使用场合
前台页面的显示控制流程要由struts控制。可以直观看到整个工作流程的操作。
可以使用基于struts 的验证和异常处理架构，简化异常处理，和数据校验的复杂度。
2.4.2.1.3 使用风险及规避
风险：struts开发工具的使用熟练度。
规避：简化开发，按模板去做，就可以降低开发风险。
2.4.2.2 JSP
2.4.2.2.1 选用理由
JSP 是编译型的动态网页程序，执行效率非常高。成功的项目经验非常丰富。可以利用java的大部分功能，是J2EE项目的最基本 前台展现技术。
2.4.2.2.2 使用场合
前台页面的展现程序。复杂页面的组合的控制程序架构。可配置的页面流跳转。
2.4.2.2.3 使用风险及规避
风险：JSP是个大容器，涉及到的技术非常多，掌握比较困难，java家族和html家族的技术都有涉及到。是混合java代码和网页html开发的模式，逻辑分工不清楚。
规避：采用MVC的架构开发，使jsp只作页面的展现，充分利用.net的前台页面技术（JavaScript操作页面的DOM树接口）。
其他业务逻辑用java的Servlet或是EJB的Session Bean 来做，可以达到分布式应用。
2.4.2.3 Java script
2.4.2.3.1 选用理由
目前CRM系统的业务复杂度都展现在前台的页面上，JSP的生命周期是页面循序执行之后，就执行完了，如果要再动态的内容展现，JSP必须要页面流的跳转再生成，这不符合目前的复杂的需求。JavaScript 弥补了JSP的不足，现在结合Microsoft最新的前台XML技术（xmlhttp）通道（IE5.5包含，在window目录的system32小有msxml.dll就可以使用），可以悄悄的与后台的Servlet 的业务逻辑交互，返回数据，再局部刷新页面。就可以使前台的视觉效果上与CS 的Delphi开发的页面没有多大的区别。这样可以减轻服务器每次动态生成Jsp的消耗，并可以使用绝大多数的.NET的技术，充分使用客户端的主机CPU和内存，服务器端就只做一样事（业务逻辑开发）以后只要有JavaScript技术结合HTML（美工）开发，就可以快速的设计页面原型，调试环境就是IE浏览器，非常方便。掌握的技术较少，html和JavaScript就可以了。JavaScript技术非常简单易学，可以降低项目风险，可以无缝集成与.NET的版本（兼容.NET版本开发）。
2.4.2.3.2 使用场合
前台页面要求局部刷新的地方。数据验证，动态的页面（Tab页的切换）。
2.4.2.3.3 使用风险及规避
风险：JavaScript是弱类型的语言（类型检查不严格），面向对象的技术较弱（它支持面向对象开发）。JavaScript是解释型的语言，效率较低 （小数据量的效率还是非常高的）。大数据量的传输不适宜。
规避：1、注意要封装JavaScript的函数；2、结合Microsoft的IE浏览器的新技术开发，效率可以得到一定程度提高；3、小数据量传输的地方可以使用。
2.4.2.4 EJB
2.4.2.4.1 选用理由
重量级的分布式远程调用的组件技术。J2EE最核心的技术。组件可以部署在不同的java虚拟机里。非常复杂的容器事务和业务补偿机制。
2.4.2.4.2 使用场合
真正需要分布式 调用的地方使用。
2.4.2.4.3 使用风险及规避
风险：1、EJB容器价格相当贵；2、分布式远程调用的资源开销非常大。特别是session状态的保留，entity Bean启动的开销；3、开发，调试非常麻烦。需要，开发，打包，部署，测试。
规避：
1、真正需要的时候使用。不需要的时候，就不使用，比如：EntityBean 就可以用OR mapping工具替换（如 Hibernate ，Toplink ，OJB）。SessionBean 里不能直接写具体的实现，必须调用 业务管理对象（BMO）来做业务实现，这样程序可以平滑过渡到 非 EJB环境的应用，保护代码投资。
2、可以用 WebService 和 轻量级的远程访问技术来 替换。轻量级远程访问技术： Cacho技术（hessian和Burlap）。
2.4.2.5 DAO
2.4.2.5.1 选用理由
现在我们做项目最好要保护代码的投资，将来遇到其他项目的需求或者本项目的需求变更升级，采用DAO模式可以屏蔽底层的具体对数据库的依赖实现。业务管理对象（BMO）只是调用DAO的接口，具体这个DAO接口是怎么操作数据库的，业务管理对象不关心，这样的话，将来，其他项目需求 是不同数据库的，就可以只写不同数据库的底层操作的DAO实现就可以了， 业务管理对象是不需要改动的 ，这样就可以保护代码投资。DAO模式还是非常容易测试的。一个个dao类实现后，测试人员就可以单元测试，一个个DAO测试通过了，才进入到业务管理对象（BMO）生产线 组装。
2.4.2.5.2 使用场合
设计到数据库具体操作的实现都可以采用。写一个接口DAO，和 具体数据库的实现DAO类，最后进入业务管理对象（BMO）装配流水线。如果不采用DAO模式，业务管理对象测试比较困难，数据库底层切换，就要大面积重写代码。
2.4.2.5.3 使用风险及规避
风险：没有风险，可能情况是DAO类比较多。
规避：把业务数据库操作的粒度放大，可以少写DAO类，但是DAO类中的方法是多了。
2.4.2.6 Hibernate
2.4.2.6.1 选用理由
Hibernate是轻量级，数据访问的 OR 映射工具。可以取代EntityBean和 JDBC 。
它是JDBC上面的一层，性能优化相当好，代码量非常少。写数据查询，比标准sql要少。
可以适用 16种不同的数据库实现，切换数据库，基本不影响业务代码。
避免了EntityBean的 多数据库实例要发布大量的JNDI名称，供调用。
2.4.2.6.2 使用场合
在对数据库操作使用，是在DAO模式里来写。
2.4.2.6.3 使用风险及规避
风险：
1、版本升级变动。
2、比如实际项目中功能没有。如调 存储过程 不支持，批量数据更新和删除，效率不高。
3、hibernate 学习掌握要时间，入门简单，精通难。
规避：
1、使用DAO模式，就可以避免 版本升级，功能不足，我可以在DAO中采用其他技术如jdbc 或是其他实现，就可以支持存储过程和批量数据更新和删除。
2、并不是说就不需要jdbc了，jdbc是不可能不用的，但是要尽量少用，应为优化太难。
3、此项目非常活跃，版本升级非常快，技术支持越来越多。
2.4.2.7 Spring
2.4.2.7.1 选用理由
Spring是在作者大量项目经验的基础上 实现的一种 简化 J2EE开发的架构。开放性做的非常好。可以部分使用Spring的类库，也可以不用。它最精华的地方就是基于javaBean的 java对象的配置机制，采用AOP（面向方面编程）或是IOC（依赖注入）技术，可以代理开发实现。比如：DAO接口和实现类，通过配置文件的配置就可以切换不同的dao实现。 整个软件开发都是可配置的。AOP技术可以横向切入，日志，数据库地址变化，事务控制，权限控制，都是可以配置的。
 面向接口编程，代码可扩展，易维护。
 基于JavaBean的配置机制，写代码基本都是javaBean的set，get机制，非常简单。
 简化开发hibernate等数据访问层的开发。
 DAO，数据源，事务控制，jndi调用 都是可配置，可替换的。
 开发的代码易于测试，基于统一接口。
 简化J2EE开发，降低项目风险，基本可以不再使用EJB。
2.4.2.7.2 使用场合
软件代码的组装配置。开发软件，就象生产流水线组装测试。
2.4.2.7.3 使用风险及规避
风险：
1、架构涵盖J2EE开发的全部部分，部分功能还在不断增强。全面掌握要时间。
2、代码开发组织形式和观念会有不同。 因为它采用了很多新的技术，AOP和IOC的观念。
规避：
1、部分使用Spring架构，供本项目使用如：基于JavaBean的配置方式，配置DAO ；集成的简化Hibernate开发的基类，就可以了。
2、本架构升级非常快，功能增强很快。开发的代码非常容易测试。





牛牛们发表下观后感啊