业务逻辑能否不依赖于持久层？

我现在的架构是po->manager->service->action
其中manager实现业务逻辑，提供事务，action调用service
service中仅获取session，控制事务，load对象，然后调用manager，所以我可以单独的测试业务而不依赖于持久层

目前有这么个场景：一张地图，分成小块。给我一个坐标和半径，然后判断这个范围内是否有水。
因为地图是上下相通，左右相通，所以我要算出这个范围内所有地块的id，然后load出来，再逐格判断
于是代码就得类似这样：
List<Integer> idList=manager.computeIdList(int x,int y);
Query query = session.createQuery("from Field where id in (:list)");
query.setParameterList("list", idList);
boolean hasWater=manager.fieldHasWater(query.list());

我想把这些东西都封到manage里，于是我定义了一个MyMap，与地块是一对多，内部用map，key为地块的id
这时会多个MyMap表，里面只有一行数据，地块表会多一列，以对应MyMap
于是manager就能写成：
boolean hasWater(int x,int y,MyMap map);
然后在内部用may.getField(int id)来得到地块
地块的数量有几十万，所以我用了lazy="extra"。

这种设计是否合理，是否会产生某些问题？


PS：<map-key type="int" formula="id" />，这种情况下不能用extra，hibernate生成的查询条件会出现null
再PS：以前看过一篇文章，select * from table where id in(1,2)的性能不如select * from table where id=1 union select * from table where id=2
因为in查询不能很好的利用索引，所以我觉得hibernate在缓存命中高的情况下，用循环load对象比用in查询要好一点，这个没测试过，高手有经验请说说