摘抄摘抄

昨天晚上想了一晚上，当前的技术都是围绕着功能测试这个角度来实现的，对于体系结构上的缺点，没有任何方面提出从测试的角度来实现，况且当前的体系结构都是采用一些非常流行的框架来实现，比如struts等，在这样的体系下，系统体系的缺点基本就是一些很小的方面了，如何发现这些小的内容的不足？
　　一直认为，在概要设计阶段对系统体系的认识都是基于经验或者知识来进行判断，而不是通过测试来，换句话说就是当前只能停留在理论的层次上对体系进行评价，这种评价是建立在当前个人的能力之上的。
　　当前的项目体系轮廓是：
　　 集中式数据库（oracle或者DB2），数据量非常大，亿条记录量级。
　　 服务通过portal来分发，所有的服务器集中部署。
　　 服务的实现分成两种：B/S、C/S，但是服务器端实现都是使用J2EE平台技术
　　 数据库服务器和应用服务器都部署cluster方式。
　　
　　 详细一些的情况是：
　　 使用struts框架以及JSP＋Taglib来实现表示层内容，
　　 业务流程的控制由struts以及部分扩展（struts扩展以及Bussiness Objects）实现，
　　 对应各个层面不同的逻辑，有vo、bo、do等对象封装具体数据及逻辑，
　　 数据存取方面：dto和ejb结合的方式实现。还不清楚是否会采用OR映射框架
　　
　　按照当前的情况，有一些预想：
　　 数据层可能问题：
　　 数据库的设计、触发器、存储过程、索引、sql语句等如何实现最根本的影响效能，对亿条数据量级的sql语句的书写如何能比较高效？
　　 使用dto方式读取数据库，其并发量的大小、缓存的原则、缓存 的大小、以及缓存的时间等内容会有直接的性能影响。
　　
　　 控制层可能问题：
　　 从感觉上说BS结构的实现，vo对象可能和do对象表达的是同一 内容；如果真是这样，vo的设计应该不存在了，而用do对象取代。
　　 业务逻辑的重用？业务逻辑非常复杂，涉及大量的数据层交互、 数据计算等内容。业务逻辑中涉及数据修改的操作基本都是非功能需求 的附加操作，其频率不是很高。频率高的原有业务需求操作基本都集中 在查询操作上了。如何重用以及用好这些业务逻辑是关键的地方。
　　 对控制层（struts）的扩展实际就是一个对请求路由的扩展， 扩展的功能的实现如何保证健壮、高效、可扩展？
============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================