浅谈业务接口封装,讨论如何将工作丢给别人

当你一天要处理过百项业务接口需求,并且要根据每项需求定义一个适当的解决方案时,当你的测试报告提交的却因为业务接口被滥用而需要面对Tester的无情驳回的时候,你就不得不和我一样,需要找到一个方法来把这些责任推到其他人的身上.(虽然这样极其混蛋,但是不得不承认这是一个非常混蛋的好办法,因为它的确提高了软件的质量,同时也提早了我的下班的时间)


关键的因素是如何有条理的把这些结构丢给其他人而他们也没有怨言呢?

1:提供足够大的自定义空间　

2:不会影响到他们现有的代码


当然还要依靠一些个人魅力和办公室手段了.游说老板和项目经理是关键的部分,一个有效而且强大的测试报告和开发过程数据统计分析,再加上你的口才.

设计上很简单,有2个主体需要遵守

1:把查询条件封装起来
2:保持接口的健壮,也就是说保证业务接口关注方向(把不重要的曝露出去)

public class ObjectQueryHandleFactory {   
   public ObjectQueryHandler openQuery() { ... };   
}  

public class ObjectQueryFilterFactory {    
   public ObjectQueryFilter openFilter() { ... };    
}  

public class ObjectQueryHandler{}  

public class ObjectQueryFilter{
   public Object executeFilter(ObjectQueryFilter oqf);
} 

public class PersonQueryHandler extends ObjectQueryHandler{}

 

public class PersonQueryFilter extends ObjectQueryFilter{} 

public class StreatQueryHandler extends ObjectQueryHandler{}  

public class StreatQueryFilter extends ObjectQueryFilter{} 

Dao设计

代码

ObjectDaoGet(ObjectQueryHandler oqh, ObjectQueryFilter oqf) {};  

这样把Query数据封装在ObjectQueryHandler这个模块组里,把Query逻辑封装在ObjectQueryFilter模块组里.处理起来非常灵活!由于你提供的只是封装,具体实现有每个开发人员自己掌握,自己的工作量少了很多，别人也不会太介意,因为下层的开发人员有很多时候的烦劳在于业务接口无从选择,或者太多的业务接口提供选择却由于不了解内部的实现方式和文档的描述而根本不懂去选择,而导致接口效率和胡乱使用接口的问题.

一个简单的用例

public class NativeQlHandleFatory extends ObjectQueryHandleFactory { 
    public NativeQlHandler open(); 
}

public class NativeQlHandler extends ObjectQueryHandler {}

/**
 * Assemble an native sql to execute
 */
public class NativeQlHandlerFilter extends ObjectQueryFilter {
    public (String)Object executeFilter(NativeQlHandler nqh){..}

}

很显然，关键的问题都被封装到ObjectQueryFilter的子类中了，而我在最上层做一下如下的操作

public class ObjectQueryFilter{
   public Object executeFilter(ObjectQueryFilter oqf) {
       // reflect annotation的模块
       oqf.execute();
   };
} 

上面的结构通过接口把 ObjectQueryHandle ObjectQueryFilter 暴露给下层的开发人员,让他们自己提供实现类的对象上来,这样做虽然没有Dao类那么直观，但却把软件整体的结构变的很紧凑，没有了大量的Dao类实现和各型个色的Dao接口，整个项目清爽了许多。

值得提一点的是JDK1.5 Annotation的引入大大的加强了我这种观念,我可以通过声明式的服务解除2者间的耦合

如

@addParam(name="clum1",value="test",factory="ObjectQueryHandleFactory")
@QueryBase(name="select")
@Query(name="from tb_person")
@Test public class StreatQueryFilter extends ObjectQueryFilter () ;

同时也可以通过代理模式来提供声明式的cache为各种接口提供一层非透明的加强

public class dynaProxyHandleBuffer()

 

这样下层的开发者可以通过下面的代码来享用全局的cache．

ObjectQueryHandler.setPropertys(new ObjectrProperty(){.......})  

当然也可以使用自定义的cache来做局部上的cache.

@Filter (Action="execute")
public class StreatQueryFilter extends ObjectQueryFilter{
   public void executeQueryFilter() { IbmCache ic = new IbmCache(); .... }
} 

好题目....
把文章再改改
多说点东西....

    我们都是自己一个人搞定，至少是一个功能模块吧。你们分工很明确，这到是一件好事。但老想着把一些工作丢给别人，这会不会引起混乱？同事会不会有怨言。是不是分工不合理，因为你的工作量太大或许其他同事相对就少。
    通过高度的抽象设计，对设计者也要求更高了。

你的工程都是小工程....
功能模块重覆的不多...

如果是大工程
每几个功能模块中就会有重覆的地方

如果分了层那么专精hibernate的人就不用去考虑页面代码的结构

可怜的hibernate牌螺丝钉。

纵向开发的话可能会出现重复
横向（分层）开发应该会好一些

再说一次大项目
如果一个模块只用一次
分不分两可

确实，我现在做的一些系统都是一些小的工程。：（

我相知道大的工程中，那些接口是怎么统一的？通过什么样的方式沟通？
比如我专门是弄hibernate的，那们我怎么知道其他同事要用到什么接口（资源）？

设计完了之后源码库里
除了DEMO之外就是一堆堆的接口
PS:所有的/**@API 文档**/都是写在接口上面的.....

总而言之是老板如何把握软件质量！

我认为大型项目有2个很明显的特点

1：无论先前的设计多么合理，想的多么周到，到了后期，出于各种考虑，设计者不得不在原有设计和客户之间做一个协调。比较好的公司，开发组实力相对平均，这种折中的方案会做的比较好,如果差一点的公司，开发组良莠不齐，而且人员流动带来的软件开发流程中的空缺最后就会导致大家都在乱拉天地线，把原先的设计改的面目全飞。

2：性能问题通常是用户最关注了！在和用户初步交流后，就是长达数月的软件重构和各式各样的测试。这时候如上几位所说(纵向分层虽然能够明确分工,但工作相对集中在业务层开发者手中，任何接口上的变更都可能会造成加了A却减了B的反效果，无用功太多)，(横向分层在这方面就会好很多，模块和接口分布的很平均，大家都遵守同一个策略，但如果开发者的水平差异明显的话，那紧接下来的就是噩梦了)

我设计这种业务接口的方式也是为了在其中找寻一个折中的方案！把业务接口所关心的部分交到一个比较强的人手中，而把比较次要的部分提交给其他相对比较弱的人。同时可以提早对各类业务接口做测试，缓解后期的压力。