牛人都喜欢一些复杂的业务逻辑,如大型的医疗系统,银行金融系统,企业OA等系统所涉及的业务。(越复杂的业务越能体现技术???)暂且不考虑这些了,任何一个业务都免不了需要对用户输入的数据进行验证吧?请大家回想一下,你所涉及的系统,有哪个业务不需要与数据打交道?
软件系统是以数据为核心的,那么操作数据的是什么?就是业务逻辑。那么一个相当重要的操作——数据验证,它属不属于业务逻辑?
我们暂且也不考虑其是不是业务逻辑,我们将从软件开发的架构上来思考一下应该把数据验证放在哪个合适的位置,是放在控制层,还是放在业务逻辑层?
假设有这样一个需求,民政部门的结婚登记——只有符合要求的男人和女人才能结婚吧?这是不可质疑的,所以我们抽象出这样几个要点:
1、只有异性才能结婚,同性不能结婚;
2、男性必须达到22周岁,女性必须达到20周岁;
3、已婚男性不能再结婚,已婚女性不能再结婚(符合一夫一妻制);离异当然是未婚处理。
在这里,我们先假定这是一个WEB应用程序,使用了Struts2,需要定义Action类。同样先假定把数据验证放到 Service业务逻辑层,所以有如下代码:
package com.wgs.service;
import com.wgs.pojo.Person;
public class PersonService {
/**
* 结婚登记业务
* @param p1
* @param p2
* @return 符合结婚条件则返回true,否则返回false
*/
public boolean marry(Person p1, Person p2) {
if (canMarry(p1) && canMarry(p2) && p1.getGender() != p2.getGender()) {
p1.setMarried(true);
p1.setPartner(p2);
p2.setPartner(p1);
p2.setMarried(true);
return true;
}
return false;
}
/**
* 判断是否符合结婚条件
* @param p
* @return 符合结婚条件返回true,否则返回false
*/
public boolean canMarry(Person p) {
if (!p.isMarried()) {
return marriedInfo(p);
} else {
return married(p);
}
}
/**
* 相应的结婚判断信息
* @param p
* @return
*/
public boolean marriedInfo(Person p) {
String name = p.getName();
boolean flag = false;
if (p.getGender() == 'M') {
if (p.getAge() >= 22) {
System.out.println(name + "男士,您好,您的年龄达到结婚要求");
flag = true;
} else {
System.out.println(name + "男士,您好,您的年龄未达到结婚要求");
}
} else if (p.getGender() == 'F') {
if (p.getAge() >= 20) {
System.out.println(name + "女士,您好,您的年龄达到结婚要求");
flag = true;
} else {
System.out.println(name + "女士,您好,您的年龄未达到结婚要求");
}
}
return flag;
}
/**
* 已经结婚信息
* @param p
* @return
*/
public boolean married(Person p) {
String name = p.getName();
if (p.getGender() == 'M') {
System.out.println(name + "男士,您好,您已经结婚啦!");
} else if (p.getGender() == 'F') {
System.out.println(name + "男士,您好,您已经结婚啦!");
}
return false;
}
}
这样,我们在控制层(Struts的Action中)就可以直接调用此业务逻辑了。为什么要这样做呢?
假定有这样一个需求,现在我们需要把这个WEB应用程序能够让Android手机客户端访问,那么我们是不是要在Android平台上设计一套具有良好用户体验的客户端界面?如果我们的数据验证代码放在Action中,那么,我们得花多少心思从Action中抽取数据验证代码放到Android平台上!而将数据验证单独作为业务逻辑后,只要Android平台上做好界面,设置相应的控制器直接调用数据验证业务逻辑就可以了。这是很方便的一件事,程序员都喜欢这样干吧?
总结来说,这样的架构具有灵活性,可维护性,可扩展性。
所以,我们应该考虑把数据验证放到业务逻辑层。想想Spring的AOP,也是同样的道理。这里就不深究啦,去吃午饭吧。
- 大小: 171.8 KB
分享到:
相关推荐
大数据-算法-学术场域的政治逻辑——一项关于学术权力的社会学考察.pdf
计算机组成实验——验证74LS181运算和逻辑功能.docx计算机组成实验——验证74LS181运算和逻辑功能.docx计算机组成实验——验证74LS181运算和逻辑功能.docx计算机组成实验——验证74LS181运算和逻辑功能.docx计算机...
大数据分析教程——制作数据报告的流程全文共9页,当前为第1页。大数据分析教程——制作数据报告的流程全文共9页,当前为第1页。大数据分析教程——制作数据报告的流程 大数据分析教程——制作数据报告的流程全文共9...
三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。
内含ppt,视频,文档,示例!!!!!!!
内含ppt,视频,文档,示例!!!!!!!
数据传输。 在做完这之后,就感觉遇到了瓶颈, 瓶颈主要来自于两个方面,第一是对 Linux 软件开发不熟悉,而 SOC FPGA 的处理器端应用又恰好需要对 Linux 的底层和应用都需要一 定的了解。 另一方面是对 FPGA 设计...
北邮——计算机——数字逻辑与数字系统 北邮——计算机——数字逻辑与数字系统 北邮——计算机——数字逻辑与数字系统 北邮——计算机——数字逻辑与数字系统 北邮——计算机——数字逻辑与数字系统 北邮——...
实验四 计数、译码和显示电路(数字逻辑)——大山.docx实验四 计数、译码和显示电路(数字逻辑)——大山.docx实验四 计数、译码和显示电路(数字逻辑)——大山.docx实验四 计数、译码和显示电路(数字逻辑)——大山.docx...
浅析互联网下半场的场景筛选逻辑——从微信小程序谈起.pdf
train.csv中存储了原始数据,每人拥有年龄,工作类型等14个维度,共32561个样本。最后一个维度为label,即收入是否大于50k。
人工智能产品的适应性创新逻辑——哈贝马斯交往理论视角.pdf
北邮——计算机——数字逻辑与数字系统 北邮——计算机——数字逻辑与数字系统 北邮——计算机——数字逻辑与数字系统 北邮——计算机——数字逻辑与数字系统 北邮——计算机——数字逻辑与数字系统 北邮——计算机...
PCL503压缩机组阀门控制逻辑——【培训课件】.pdf
大数据-算法-学校组织的行动逻辑——行动者的观点.pdf
人工智能时代人机关系的变革逻辑——基于ChatGPT应用的学术考察.pdf
浅析互联网下半场的场景筛选逻辑——从微信小程序谈起
大数据背景下现代农业连锁品牌演化逻辑——基于物流供应链的分析.pdf
大数据背景下现代农业连锁品牌演化逻辑——基于物流供应链的分析