今天是设计培训的最后一天，在讲依赖倒置的问题的时候，突然说出一句话：No User，No Interface
此时想起一个问题，那就是界面查询中条件和结果应该如何传递给后台服务类的问题，一时不禁呆住。
前提：
界面知道查询条件和需要什么样的结果，因此必须要由他将有关的需求传递给后台服务类。
例如：我们需要根据工龄查询工龄在10年以上的员工，需要显示员工的姓名、部门、编号。
我应该如何传递这个信息，如果我们将需要显示这个信息的界面命名为：UIWorkAgeSearch
对应的UI服务的接口为：IWorkAgeSearchService
对应的服务为 WorkAgeSearchService
如图：
问题是界面应该如何告诉服务类它需要什么要的返回数据呢？
一个方式：
我们增加一个WorkAgeSearchData的数据接口，要求返回的数据必须是该接口的一个实现。
或者定义一个与界面传递的数据结构，来进行本工作。
可我担心的是，现在的系统UI是客户最喜欢修改的，如果他想增加员工的Code，那我就不得不修改UIWorkAgeSearch、IWorkAgeSearchData、WorkAgeSearchService等部分。
这明显将这三者粘连到一起，粘连的臭味明显。
方式二：
一些人喜欢在UI里面将SQL组装好，然后传递到统一的SQLHelper类中执行。返回DataSet或者DataTable。
这是我不喜欢的，一：这导致界面层的人员必须了解SQL语法、必须知道后台使用啥数据库，对数据库方言也要了解等等。二：限制了我必须使用数据库，我可能想使用Hibernate来缓存数据。三：可能查询并不这么简单，组装SQL就可以了，可能需要从某个服务先获得某些数据，然后才能执行。
方式三：
在配置文件中定义好条件和需要的结果，让后台服务读取这个配置，我想几乎所有的查询都会涉及到多个实体的关系，所以这个定义会否过于复杂，那会不会复杂到干脆将SQL语句准备好这个程度呢。
方式四：
在配置文件中准备好SQL语句，条件嘛通过配置转递。
这几种方式，我都不喜欢，不知道大家的看法如何。
我的意见是：查询条件与结果都是界面所需要的，因此，一定是界面告诉后台服务类的，关键是后台服务类如何能够不和界面有如此尽力的连接呢？
请各位支招。
此时想起一个问题，那就是界面查询中条件和结果应该如何传递给后台服务类的问题，一时不禁呆住。
前提：
界面知道查询条件和需要什么样的结果，因此必须要由他将有关的需求传递给后台服务类。
例如：我们需要根据工龄查询工龄在10年以上的员工，需要显示员工的姓名、部门、编号。
我应该如何传递这个信息，如果我们将需要显示这个信息的界面命名为：UIWorkAgeSearch
对应的UI服务的接口为：IWorkAgeSearchService
对应的服务为 WorkAgeSearchService
如图：
问题是界面应该如何告诉服务类它需要什么要的返回数据呢？
一个方式：
我们增加一个WorkAgeSearchData的数据接口，要求返回的数据必须是该接口的一个实现。
或者定义一个与界面传递的数据结构，来进行本工作。
可我担心的是，现在的系统UI是客户最喜欢修改的，如果他想增加员工的Code，那我就不得不修改UIWorkAgeSearch、IWorkAgeSearchData、WorkAgeSearchService等部分。
这明显将这三者粘连到一起，粘连的臭味明显。
方式二：
一些人喜欢在UI里面将SQL组装好，然后传递到统一的SQLHelper类中执行。返回DataSet或者DataTable。
这是我不喜欢的，一：这导致界面层的人员必须了解SQL语法、必须知道后台使用啥数据库，对数据库方言也要了解等等。二：限制了我必须使用数据库，我可能想使用Hibernate来缓存数据。三：可能查询并不这么简单，组装SQL就可以了，可能需要从某个服务先获得某些数据，然后才能执行。
方式三：
在配置文件中定义好条件和需要的结果，让后台服务读取这个配置，我想几乎所有的查询都会涉及到多个实体的关系，所以这个定义会否过于复杂，那会不会复杂到干脆将SQL语句准备好这个程度呢。
方式四：
在配置文件中准备好SQL语句，条件嘛通过配置转递。
这几种方式，我都不喜欢，不知道大家的看法如何。
我的意见是：查询条件与结果都是界面所需要的，因此，一定是界面告诉后台服务类的，关键是后台服务类如何能够不和界面有如此尽力的连接呢？
请各位支招。
