项目所得:一个非典型性改动带来的思考(二) 之对第一个问题的思考

上篇 里以一个简化的例子把问题描述了下, 这里将当时引发的思考记录下来.

    1, 接口配以不同的实现, 好像设计模式里有这么一个叫"策略"模式的. 大致想法是这样的, 定义一个名为CriteriaProvider的接口, 接口可以写以这样:

 public interface CriteriaProvider{
      boolean isPass(Student student);
}

 

   再依两套标准做不同的实现.
   这样是可以解决在项目里调用的问题, 但由于原有判断在代码中很多分散而改动很多的毛病没有解决. 如果设计之初考虑到判断标准有可能会改,做这样的接口还是可以, 不过现在项目已快成了,再做这样处理有些得不偿失,

    2, 针对分散的特点,想到AOP编程. 原有的硬编码的方式的分散有两个特点, 一是从广度上来看的分散广, 细数了下,有十多处. 二是从层次上的分散广, 不仅action中有判断, DAO实现中也有类似的判断. 这样的"枝蔓纵生"不是正好迎合了AOP的特点吗? 做个AOP再配置下,怎样?
      看似有些华丽了.
      AOP的概念知道, 自己也配置过Spring自带的AOP,但要是自己结合现有的业务逻辑实现一套还真有些发怵.
这个念头想了想就pass掉了, 不过现在回过头来看,也算是看到了一个自己实现AOP机会, 也就有心思想着以后若有时间自己搞一个小的实现先练练手.

   3, 所有的数据都是通过hibernate从数据库得到的, 能不能用Hibernate里Interceptor,loadEventListener或filter呢? 若可以实现的话, 就从根上解决了问题, 省的在代码中做那么多的修改.
有了这个念头后, 梳理了下hibernate里相关的技术.
      最大困难跟AOP类似, 自己看到hibernate里有这样的概念但自己也是一次也没用过, 甚至连小实验也做过, 现在突然拿到项目中来用,风险太大. 随便说下, 当时看Hibernate里这些概念时,感叹Hibernate的设计及功能强大之余, 心里也念叨自己怕一时半会儿也用不到这个高级东东的. 有了这样的想法后,做个针对实验的想法也就没了. 现在看来, 这个机会也倒是刺激了我想加深理解这些高级用法的冲动.

   4, 从最初的源头数据库着手干. 既然Hibernate的技术可以做到,那在数据库里做不是更干的彻底? 我的想法是这样的, 往Student表里加一个标志位, 当有记录添加或改动时用一个Trigger来判断下是否达标.
这个想法更不可能, 表里不是可以随便加字段的, Trigger也更没写过.

    这样,针对第一个问题, 从浅到深地想到这些条实现的可能.围绕这个思考的过程,又有一些关键词蹦了进来: 数据库实现业务逻辑, 现在项目的套路及缺点, 程序设计的美.这篇不能写了, 下篇见吧.