java开源文档大全致力于打造中国最大最全的开源文档,它提供了最全面最权威的开源资料,同时为大家提供一个交流的平台,如果您有好的想法,欢迎您投稿.
当你一天要处理过百项业务接口需求,并且要根据每项需求定义一个适当的解决方案时,当你的测试报告提交的却因为业务接口被滥用而需要面对Tester的无情驳回的时候,你就不得不和我一样,需要找到一个方法来把这些责任推到其他人的身上.(虽然这样极其混蛋,但是不得不承认这是一个非常混蛋的好办法,因为它的确提高了软件的质量,同时也提早了我的下班的时间)关键的因素是如何有条理的把这些结构丢给其他人而他们也没有怨言呢? 1:提供足够大的自定义空间 2:不会影响到他们现有的代码 当然还要依靠一些个人魅力和办公室手段了.游说老板和项目经理是关键的部分,一个有效而且强大的测试报告和开发过程数据统计分析,再加上你的口才. 设计上很简单,有2个主体需要遵守 1:把查询条件封装起来
2:保持接口的健壮,也就是说保证业务接口关注方向(把不重要的曝露出去) 代码 代码 代码 代码 代码 代码 代码 代码 Dao设计 代码
代码 这样把Query数据封装在ObjectQueryHandler这个模块组里,把Query逻辑封装在ObjectQueryFilter模块组里.处理起来非常灵活!由于你提供的只是封装,具体实现有每个开发人员自己掌握,自己的工作量少了很多，别人也不会太介意,因为下层的开发人员有很多时候的烦劳在于业务接口无从选择,或者太多的业务接口提供选择却由于不了解内部的实现方式和文档的描述而根本不懂去选择,而导致接口效率和胡乱使用接口的问题. 一个简单的用例 代码 代码 代码 很显然，关键的问题都被封装到ObjectQueryFilter的子类中了，而我在最上层做一下如下的操作 代码 上面的结构通过接口把 ObjectQueryHandle ObjectQueryFilter 暴露给下层的开发人员,让他们自己提供实现类的对象上来,这样做虽然没有Dao类那么直观，但却把软件整体的结构变的很紧凑，没有了大量的Dao类实现和各型个色的Dao接口，整个项目清爽了许多。 值得提一点的是JDK1.5 Annotation的引入大大的加强了我这种观念,我可以通过声明式的服务解除2者间的耦合 如 代码 同时也可以通过代理模式来提供声明式的cache为各种接口提供一层非透明的加强 代码 这样下层的开发者可以通过下面的代码来享用全局的cache． 代码 当然也可以使用自定义的cache来做局部上的cache. 代码
java开源文档研究struts,webwork,spring,tomcat,jboss,lucense,nutch,JUnit,eclipse......,如果您有什么意见,欢迎评论和留言. |
