上层建筑和下层建筑

 

现在的开发架构一般都是三层或四层架构，较下的层总是提供接口或方法给上层调用，这时就遇到一个问题了：调用下层接口或方法的时候，传入的参数需要怎样验证正确性呢？如果两个层次之间是属于同一个项目或是同一个公司的项目的话可能还可以查看一下源代码，看一下下层的实现方法是否有验证参数的正确性，但如果是使用其它的类库，我们无法看到源代码的时候咋办？甚至有时候在同一个公司，同一个项目中，下层接口方法的编写者也不知道该不该在每个方法里验证参数是否正确，是否不为null（这个最常见了）。

       这个时候，大家都应该遵守一种业务的约定，很多问题便能迎刃而解了。下面举两个小例子：

Action

Service

Page listData()

在上图中，Action调用Service中的一个返回类型为Page的listData的方法，然后再作小许的加工就可以将Page中的数据放到页面中显示了。在这种场景下，页面对Page中有没有数据其实是不关心的，Action并不会检验（也没有必要）Page里是否有数据，只要Page里的数据不为null就可以了（要清楚没有数据跟null的区别），因此，Service的listData接口返回的Page一定不能为null。

         如果上图中的listData方法改为返回类型为MapUser的getUser方法，则又有另一种说法了。getUser方法的使用场景大部份是必须要查出真实数据的对象的，当Action传入的参数在Service里查不到数据的话，Service绝不能返回一个不带任何数据的MapUser对象，而是返回null就可以了，让Action自己作判断，然后做应该做的事。