spring整合mongoDB-3

使用起来就简单了。

还有像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存储的时候。