数据完整性的检查
前两天就产生的这个数据完整性的问题,只是当时没有记录下来,现在回想了一下感觉还是记录下来比较好.
数据完整性主要解决的问题就是数据的合法性,想像一下一个多对多关联表的关联数据都是无效是会是多么大的一个问题,这个问题在上一家公司的时候我就问公司的高手们的,但他们只给我讲了有两种处理方式,但没有对每种方式讲个所以然,他们都偏向于使用代码进行检查，也就是在领域层中进行检查，同时我看MS的WEBCAST时有一位讲师讲的应当使用数据库的约束等进行检查。同时看到更多的开源代码和同事就是直接在UI层中进行检查就完了，其它的根本就没有做什么。这里根据我的理解和所查阅的资料，记录一下我自己的看法。
首先记录一下数据完整性的处理范围，这个范围包括领域模型属性是否充许为空，字符串属性长度是否过长，父子表中子表列中的值是否在父表中存在，数字属性值是否在指字范围内和其它的一些约束。
其次记录一下处理这个问题的三种方式和各自的优势：
第一种方式：使用数据库提供的数据完整性检查来进行，这种方式对于检查关联表关系特别容易。能够有效的利用数据库的强大优势，能够通过数据库的约束来保证各软件向数据库中添加的数据都能够保证完整性，在早期应用中可能可能100%都是利用这种方式进行的。不足之处在于对于数据库的信赖性强，数据移值时复杂，并且需要对数据库有很多的了解，同时有些数据完整性的检查可能在软件中不易捕获和处理，比如SqlServer中所有的数据访问异常都返回SqlException，需要能够自定义的处理程序将这种异常进行完整性方面的异常转换，只有这样才能够显示出对用户有效的提示，避免向用户提供过多的系统内部信息不利于系统的安全，并且有时这种转换是很不容易完成的，如:SqlException中需要获得那个字段无能为空，就还需要从数据消息中获取并转换为相应的领域对象属性，同时还需要考虑不同语言版本所产生的问题，最后会让异常捕捉和转换这部分的代码臃肿不堪难以理解。
第二种方式：是在领域层中进行检查，这中方式应当说是一种新兴的处理方式，很多程序都在逐步采用这种方式来进行检查。这种方式的优势就是可以用来检查数据库不能检查的不规则的完整性要求，如EMAIL格式规则等，同时错误非常明确，编写单元测试也很容易。不足之处在于像检查表关联关系这种可能会很麻烦，需要多次访问数据库，并且如果需要删除关联数据可能还会执行很多删除方法，性能可能会有所下降，随着关系关系的增加还需要修改代码来适应这种变化。并且如果一个数据库需要由多个软件应用可能就需要编写多次相同的代码，很能可能产生不完整的数据，并且如果像字符串不为空这种代码都需要检查的话，会让整个检查部分的代码臃肿不堪。但现在也有部分自动进行这种处理的验证程序，MS EL中的验证应用块就是用来处理这一问题的一个方法。我前面也编写了这样一个验证组件。
第三种方式：直接在UI中进行检查，这种方式其实是我个人认为不值得推荐的方式，这种方式可能会产生不安全的因素，特别是像SOA开发中应当严格禁止。这种方式的优势是简单。不足是可能会产生很多废弃的数据，并且也不能保证数据的完整性。
这三种方式各有各的好处和优势，在这里我个人认为三种处理方式经过我的认为我认为第一种方式经比较好，因为这种方式可以保证数据绝对完整性，就像直接就SQL企业管理器录入的数据也必须通过检查，同时还需要在界面层进行像非空,字符长度等方面的检查，通过数据库来保证一对多或多对多这种关系的正确性，对于数据库不能进行的检查采用编写的方式来进行检查，如Email或其它自定义字符串检查检查等。对于错误的提示，如果是使用性要求比较高的时候应当通过统一的数据异常处理程序来处理，如果是要求不高的情况下，直接提示发生错误，减少开发时间。
并且我认为采用最简单的方式达到所需要的效果应发是最好的解决方法，不应当为了什么而做什么。
数据完整性主要解决的问题就是数据的合法性,想像一下一个多对多关联表的关联数据都是无效是会是多么大的一个问题,这个问题在上一家公司的时候我就问公司的高手们的,但他们只给我讲了有两种处理方式,但没有对每种方式讲个所以然,他们都偏向于使用代码进行检查，也就是在领域层中进行检查，同时我看MS的WEBCAST时有一位讲师讲的应当使用数据库的约束等进行检查。同时看到更多的开源代码和同事就是直接在UI层中进行检查就完了，其它的根本就没有做什么。这里根据我的理解和所查阅的资料，记录一下我自己的看法。
首先记录一下数据完整性的处理范围，这个范围包括领域模型属性是否充许为空，字符串属性长度是否过长，父子表中子表列中的值是否在父表中存在，数字属性值是否在指字范围内和其它的一些约束。
其次记录一下处理这个问题的三种方式和各自的优势：
第一种方式：使用数据库提供的数据完整性检查来进行，这种方式对于检查关联表关系特别容易。能够有效的利用数据库的强大优势，能够通过数据库的约束来保证各软件向数据库中添加的数据都能够保证完整性，在早期应用中可能可能100%都是利用这种方式进行的。不足之处在于对于数据库的信赖性强，数据移值时复杂，并且需要对数据库有很多的了解，同时有些数据完整性的检查可能在软件中不易捕获和处理，比如SqlServer中所有的数据访问异常都返回SqlException，需要能够自定义的处理程序将这种异常进行完整性方面的异常转换，只有这样才能够显示出对用户有效的提示，避免向用户提供过多的系统内部信息不利于系统的安全，并且有时这种转换是很不容易完成的，如:SqlException中需要获得那个字段无能为空，就还需要从数据消息中获取并转换为相应的领域对象属性，同时还需要考虑不同语言版本所产生的问题，最后会让异常捕捉和转换这部分的代码臃肿不堪难以理解。
第二种方式：是在领域层中进行检查，这中方式应当说是一种新兴的处理方式，很多程序都在逐步采用这种方式来进行检查。这种方式的优势就是可以用来检查数据库不能检查的不规则的完整性要求，如EMAIL格式规则等，同时错误非常明确，编写单元测试也很容易。不足之处在于像检查表关联关系这种可能会很麻烦，需要多次访问数据库，并且如果需要删除关联数据可能还会执行很多删除方法，性能可能会有所下降，随着关系关系的增加还需要修改代码来适应这种变化。并且如果一个数据库需要由多个软件应用可能就需要编写多次相同的代码，很能可能产生不完整的数据，并且如果像字符串不为空这种代码都需要检查的话，会让整个检查部分的代码臃肿不堪。但现在也有部分自动进行这种处理的验证程序，MS EL中的验证应用块就是用来处理这一问题的一个方法。我前面也编写了这样一个验证组件。
第三种方式：直接在UI中进行检查，这种方式其实是我个人认为不值得推荐的方式，这种方式可能会产生不安全的因素，特别是像SOA开发中应当严格禁止。这种方式的优势是简单。不足是可能会产生很多废弃的数据，并且也不能保证数据的完整性。
这三种方式各有各的好处和优势，在这里我个人认为三种处理方式经过我的认为我认为第一种方式经比较好，因为这种方式可以保证数据绝对完整性，就像直接就SQL企业管理器录入的数据也必须通过检查，同时还需要在界面层进行像非空,字符长度等方面的检查，通过数据库来保证一对多或多对多这种关系的正确性，对于数据库不能进行的检查采用编写的方式来进行检查，如Email或其它自定义字符串检查检查等。对于错误的提示，如果是使用性要求比较高的时候应当通过统一的数据异常处理程序来处理，如果是要求不高的情况下，直接提示发生错误，减少开发时间。
并且我认为采用最简单的方式达到所需要的效果应发是最好的解决方法，不应当为了什么而做什么。
