关于service层、dao层，以及O/R Mapping之间的思考
部门最近正式进入oo的开发，采用了类似于petshop4的层次结构，简单来说，service层调用dao（当然是用配置文件+反射的方式），dao通过ibatis.net完成从数据库中的table到domain对象的映射。这样做的目的，当然是希望能够让各个层次各司其职，减少层次之间的耦合，结构分明。同时，结合tdd以及mock，完成各个层次之间的并行开发。
不过这几天的开发，给我带来一些疑惑。用过ibatis.net的兄弟们都知道，兄弟们需要自己动手写映射文件，写sql来完成mapping的过程。mapping不用多说，就是这个sql，让我觉得有点迷茫。
比如一个最普通的取得列表的方法getlist，通常这种列表方法都是要带着查询参数的。那么这些查询的条件应该在哪个层次中处理？ dao么？service层？现在我们的处理方式是在ibatis.net的mapping的配置文件中写sql来完成查询，dao接口中定义方法签名，然后在dao实现中组织查询条件，service层调用dao层的getlist方法。针对这种方式，我的问题是：
1、按照我的理解，查询条件应该算是业务逻辑的一个组成部分，那么把查询条件放到sql里面处理，是不是违背了各个层次之间的职责分配？如果真的把筛选数据的过程放到service处理，那么对于大数据量的情况，效率问题如何解决？在这个问题上，没记错的话，nhibernate是通过hsql来处理的。那么nhibernate对缓存是怎么处理的？
2、按照我们的方式，如果结合tdd，service层实际上就不包含任何逻辑，对service的测试就不存在太大意义了。
除了上面的问题之外，为了测试dao层，我们试图用事务来控制对dao的测试，但是在分布式事务的处理上面总是有问题，这个应该怎么设置？
不过这几天的开发，给我带来一些疑惑。用过ibatis.net的兄弟们都知道，兄弟们需要自己动手写映射文件，写sql来完成mapping的过程。mapping不用多说，就是这个sql，让我觉得有点迷茫。
比如一个最普通的取得列表的方法getlist，通常这种列表方法都是要带着查询参数的。那么这些查询的条件应该在哪个层次中处理？ dao么？service层？现在我们的处理方式是在ibatis.net的mapping的配置文件中写sql来完成查询，dao接口中定义方法签名，然后在dao实现中组织查询条件，service层调用dao层的getlist方法。针对这种方式，我的问题是：
1、按照我的理解，查询条件应该算是业务逻辑的一个组成部分，那么把查询条件放到sql里面处理，是不是违背了各个层次之间的职责分配？如果真的把筛选数据的过程放到service处理，那么对于大数据量的情况，效率问题如何解决？在这个问题上，没记错的话，nhibernate是通过hsql来处理的。那么nhibernate对缓存是怎么处理的？
2、按照我们的方式，如果结合tdd，service层实际上就不包含任何逻辑，对service的测试就不存在太大意义了。
除了上面的问题之外，为了测试dao层，我们试图用事务来控制对dao的测试，但是在分布式事务的处理上面总是有问题，这个应该怎么设置？
