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

本文介绍了一项项目中的非典型改动,即将原本硬编码的判断标准迁移到数据库,并允许灵活调整。面对复杂的业务场景,文章探讨了如何在分散的代码库中统一更新规则,并利用Hibernate框架描述这些规则。

引言: 这些天项目中做了一个改动, 为了后续行文方便,我们给这个改动起个绰号,称之为"非典型改动". 围绕这个改动,我想了很多, 几乎贯穿了整个项目所用的技术. 现在我想整理下来,作为以后的一个参考, (不敢写"若对别人有所帮助我也甚感欣慰"这样的话了, 因为这些天写博客写的有些伤心, :-) ).
----------------------------------------
这是一个真实的故事.

事情是这样的. 项目中的一个类,对这个类中一属性的判断规则是在代码里写死的. 由于现在的判断标准很简单,它们都是在代码中写死的. 现在要改, 把判断标准改放到数据库里, 而且判断标准要复杂了些.
为了更形象地描述这个问题, 也为了后续博客中写的方便, 在这篇博客里在下用一个简单的模型来描述下.

假设有一个类, Student, 它的属性如下.

class Student{
String id;
int age;
double score;
}

结合这个类把现在项目中的问题描述下. 我们知道,现在确定一个Student是否通过一个考试是看他的分数是否大于60, 现在判断标准改了, 它的规则如下:
如果 age > 20 && age < 21 && score > 65, --> "恭喜你, 过关了"
如果 age > 15 && age < 20 && score > 55, --> "恭喜你, 过关了"
............
也就是说判断的标准考虑到年龄因素了, 这样的组合有很多种, 于是判断组合是写在了数据库, 而且"老师"可以随时更改判断标准.

再回到项目中, 现在的问题是:
1, 项目中对一个Student是否通过考试的判断很多,也很散, 有在action中的, 也有在底层DAO实现的.
2, 项目中用的Hibernate怎么来描述判断标准.

这篇先到这里, 在下一篇中将写第一个问题引发的思考.

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值