业务逻辑——谈谈数据验证

      牛人都喜欢一些复杂的业务逻辑，如大型的医疗系统，银行金融系统，企业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，也是同样的道理。这里就不深究啦，去吃午饭吧。