我认为在一个项目中,数据库的设计和构件是最重要的!
在数据库的设计中,对领域模型的定义是最关键的.它的合理决定了数据库中的表结构的合理.随着项目经验的丰富,我开始总结出一些常规的开发步骤.首先,对从需求中提取出业务对象,然后理清它们之间的从属性.这些特性必须是遵循食物的客观合理性的.比如现在我们已经分离出班级和学生两个模型,我们应该很容易理解它们之间的从属关系.班级你可以独立地插入数据库中,但是学生是不能独立存在.它必须和某个班级相关联起来.否则就会有插入的异常.其次,根据从属关系,找出最小微粒的查询条件.因为最复杂的查询结果也是结合各个基本的查询条件,才查询出来的.在这层我们完全可以不去考虑业务逻辑的复杂性.
中石油的卡系统的表结构,我在写服务方法时,因为对表结构理解的不是很顺,在写操作的时候思路非常的不清晰流畅! 这样对查询条件的使用非常的不合理,甚至可能达不到业务需求! 一下两段代码就很说明问题:
//这是对表和实体未充分理解下,写下的代码
if(status == 3){
if(cardRequestOrder.cardType == 4){
Query drivers = ejbService.creatQuery("select o from CardUser as o where o.cardRequestOrder=?");
drivers.setParameter(0,cardRequestOrder);
List drvier_list = drivers.list();
Iterator driver_iterator = drvier_list .iterator();
while(driver_iterator.hasNext()){
CardUser driver_or_company = (CardUser)driver_iterator.next();
Query companys = ejbService.creatQuery("select o from CardUser as o where o.orgUser=?");
driver_or_company.cardRequestOrder = null;
driver_or_company.merge();
List company_list = companys.list();
Iterator company_iterator = company_list.iterator();
while(company_iterator.hasNext()){
CardUser cardUser = (CardUser)company_iterator.next();
CardRequestMapping cardRequestMapping = CardRequestMapping.loadByCardUser();
cardRequestMapping.remove();
}
}
cardRequestOrder.remove();
}
}
以下是充分理解表和实体关系后的对同一功能的重新编码:
if(status == 3){
if(cardRequestOrder.cardType == 4){
Query drivers = ejbService.creatQuery("select o from CardUser as o where o.cardRequestOrder=?");
drivers.setParameter(0,cardRequestOrder);
List driver_list = drivers.list();
driver_list.each(){
it.cardRequestOrder = null;
it.merge();
}
Query cardRequestMappings = ejbService.creatQuery("select o from CardRequestMapping as o where o.cardRequestOrder=?");
cardRequestMapping.setParameter(0,cardRequestOrder);
List cardRequestMappings_list = cardRequestMappings.list();
cardRequestMappings_list.each(){
it.remove();
}
}
现在对中石油卡系统的数据库的理解已经很透彻了,所以现在写服务方法简直是在浪费我的生命!已经没有理由支撑我再做这样的事情.我想以后更多的关注点是在数据库的设计和一些敏捷开发上.POS和页面处理也很有兴趣,尽管我是多么的厌恶脚本!
在数据库的设计中,对领域模型的定义是最关键的.它的合理决定了数据库中的表结构的合理.随着项目经验的丰富,我开始总结出一些常规的开发步骤.首先,对从需求中提取出业务对象,然后理清它们之间的从属性.这些特性必须是遵循食物的客观合理性的.比如现在我们已经分离出班级和学生两个模型,我们应该很容易理解它们之间的从属关系.班级你可以独立地插入数据库中,但是学生是不能独立存在.它必须和某个班级相关联起来.否则就会有插入的异常.其次,根据从属关系,找出最小微粒的查询条件.因为最复杂的查询结果也是结合各个基本的查询条件,才查询出来的.在这层我们完全可以不去考虑业务逻辑的复杂性.
中石油的卡系统的表结构,我在写服务方法时,因为对表结构理解的不是很顺,在写操作的时候思路非常的不清晰流畅! 这样对查询条件的使用非常的不合理,甚至可能达不到业务需求! 一下两段代码就很说明问题:
//这是对表和实体未充分理解下,写下的代码
if(status == 3){
if(cardRequestOrder.cardType == 4){
Query drivers = ejbService.creatQuery("select o from CardUser as o where o.cardRequestOrder=?");
drivers.setParameter(0,cardRequestOrder);
List drvier_list = drivers.list();
Iterator driver_iterator = drvier_list .iterator();
while(driver_iterator.hasNext()){
CardUser driver_or_company = (CardUser)driver_iterator.next();
Query companys = ejbService.creatQuery("select o from CardUser as o where o.orgUser=?");
driver_or_company.cardRequestOrder = null;
driver_or_company.merge();
List company_list = companys.list();
Iterator company_iterator = company_list.iterator();
while(company_iterator.hasNext()){
CardUser cardUser = (CardUser)company_iterator.next();
CardRequestMapping cardRequestMapping = CardRequestMapping.loadByCardUser();
cardRequestMapping.remove();
}
}
cardRequestOrder.remove();
}
}
以下是充分理解表和实体关系后的对同一功能的重新编码:
if(status == 3){
if(cardRequestOrder.cardType == 4){
Query drivers = ejbService.creatQuery("select o from CardUser as o where o.cardRequestOrder=?");
drivers.setParameter(0,cardRequestOrder);
List driver_list = drivers.list();
driver_list.each(){
it.cardRequestOrder = null;
it.merge();
}
Query cardRequestMappings = ejbService.creatQuery("select o from CardRequestMapping as o where o.cardRequestOrder=?");
cardRequestMapping.setParameter(0,cardRequestOrder);
List cardRequestMappings_list = cardRequestMappings.list();
cardRequestMappings_list.each(){
it.remove();
}
}
现在对中石油卡系统的数据库的理解已经很透彻了,所以现在写服务方法简直是在浪费我的生命!已经没有理由支撑我再做这样的事情.我想以后更多的关注点是在数据库的设计和一些敏捷开发上.POS和页面处理也很有兴趣,尽管我是多么的厌恶脚本!