还有像executeCommand支持复杂操作的接口。
使用Criteria可以构造Query,支持大于、小于、in等查询条件,类似于Hibernate的Criteria。
@Service("myService") public class TestService { private Logger log = Logger.getLogger(getClass()); private MongoTemplate mongoTemplate; public List<User> findAll(String collectionName) { return mongoTemplate.findAll(User.class, collectionName); } public void save(String collectionName, List<User> items) { if (StringUtils.isNotEmpty(collectionName)) { mongoTemplate.dropCollection(collectionName); mongoTemplate.insert(items, collectionName); } else { log.error("name does not exist."); } } public void delete(String collectionName) { if (StringUtils.isNotEmpty(collectionName)) { mongoTemplate.dropCollection(collectionName); } else { log.error("name does not exist."); } } @Autowired public void setMongoTemplate(MongoTemplate mongoTemplate) { this.mongoTemplate = mongoTemplate; } }
但是说实话,像涉及到DBObject、Query这样的接口,一般使用起来都比较麻烦,我之前使用Hibernate的Criteria很有感触,所以比较反感使用这些。
比如,有一个深层嵌套的关联,User-Org-Address-postcode。
要按邮编和电话筛选,要用and把两个eq连接起来,但是使用eq之前,你还得判断中间的Org,Address是否为空,否则你调xxx.xxx.xxx.getPostCode会抛空指针。
这样写出来的代码真像某地的护城河,又臭又长。
所以在类似的api里写复杂查询的缺点如下:
1、代码冗长,开发效率低下;
2、逻辑不直观,容易出错,不好维护;
3、复杂的查询性能不好。比如可能在mongoDB里不能使用索引。这是很多nosql产品本身的特点决定的。
4、复杂的查询很难做cache,不容易优化;
5、复杂的查询不容易复用;
6、复杂的查询很难移植。特别是如果有一天要转向K-V存储的时候。