前言

之前的文章中提到mgo的使用方式是基于session对象的，关于mgo与session，参考旧文mgo的session与连接池。本文将会探讨我们在生产中是具体如何使用这个库的。不意在确定一种万用的“正确”方法，而是记录一下方便日后批评与自我批评（XD）。

当然，严格来说，这个问题跟golang语言的使用没啥关系；但我就是觉得之前的使用方法很枯燥，好气哦！

stateless的包方法使用

顾名思义，就是将mongo的各种数据库操作写成一个个方法调用，比如要根据id查找一条文档，那么就有如下的exported package function

package mongo

func FindById(id) (DocStruct, err){
	session := GETSESSION()
	defer session.Close()
	Doc := DocStruct{}
	err := session.DB.C.Find({},&Doc)
	return Doc, err
}

使用的时候就是在业务代码中，调用一下这个方法。

func () {
	doc ,err:= mongo.FindById(id)

}

这种操作，我自己称之为无状态（stateless）的数据库操作，因为这种操作只是一个动作，他也不会涉及到管理任何的连接或者数据状态。当然这种写法是没什么问题，在操作简单、固定的情况下；吹毛求疵的话，就是session的行为不太好控制。

但是当数据库操作变得复杂，一个结构的行为多样化的时候，就会产生很多这样的方法。比如需要根据id，对某个字段CRUD，那就要产生四个方法，在业务代码中进行组合。还有一些更复杂的针对mongo 嵌套文档的CURD就更是如此了。这样的问题第一是，要产生多个session对象，其实完全没必要，（session获得连接的效率问题在旧文中也提到过）；另一个是操作很多，操作过于松散，总感觉不好维护。有时候甚至会忘记某个操作之前实现过，而写了个差不多得方法满足新的需要。

新项目中的尝试

首先上帝说要有对象

在目睹了一个包中，针对无数个文档有无数野生方法的惨状以后，我决定放弃这种exported package function的类C用法。我觉得使用struct抽象出对象模型，每个对象的声明周期内，都会持有一个session，在对象结束时使用session。这样的话，一个文档生命周期内所有的操作，就并不必产生多余的session对象，对mgo的并发问题也更加友好。struct拥有自己的CURD操作，感觉也更规整一些。

具体我是这么做的。

有一个以文档为单位的interface{}

type IDoc interface {
	DB () string
	Col() string
	Close()
}

假设有一个mongo collection存储着数据模型为Person的数据

type Person struct{
	Id bson.ObjectId `bson:"_id"`
	Name string `bson:"name"`
	Age int `bson:"age"`
}

首先规定所有的文档结构定义都要实现IDoc的接口，当然其实这个卵用不大，只是希望规范一下模型；具体用处下文细讲。

其实不实现也没问题，IDoc不是作为一个操作抽象存在的；但我还是会在全局定义的地方写

var _ IDoc = &Person{}

保证实现了方法。

然后上帝说要善待session

定义了一个包装mgo.Session的结构体。（我这次不希望mgo的import在我的项目里到处跑）

type SessionHelper struct {
	*mgo.Session
}

func (s *SessionHelper)CloseHelper() {
	s.Close()
}

重新定一下Person，让他持有一个SessionHelper

type Person struct{
	SessionHelper `bson:"-"`
	Id bson.ObjectId `bson:"_id"`
	Name string `bson:"name"`
	Age int `bson:"age"`
}

之后就可以基于这样的结构，实现任意的CRUD方法，比如：

func (p *Persion) GetName() ()string,error){
	p.DB(p.DB()).Col(p.Col()).Find(bson.M{...}).Select(bson.M{...})
	...

对于业务代码来说，复杂的sql在method receiver上去现实，外部不关心的操作可以匿名；对session非常友好。

当然，doc还需要New方法

func NewPerson() *Person{
	return &Person{	
		SessionHelper:GETSESSION(),
	}
}

使用时候的画风就是

func foo() {
	p := NewPerson()
	defer p.Close()
	p.LoadById(id)
	p.GetName()
	...
	p.DoXXX()

}

反正我觉得比如下这种nice很多。包方法毕竟是共享名字的，有时候不看代码也搞不太清一个方法到底是要操作哪个数据结构。

func foo() {
     p := &Person{}
     p.Name = mongo.FindName(id)
     p.xxx = mongo.Findxxx()
    ...
}

一个缺点

大概一个缺点就是，因为集成了session，每个对象在生成以后必须手动Close，否则会造成mgo的连接泄露。其实这跟每次生成session的方法是一样的，也是要成对生成释放的，也没差。

爬坑时间

golang的作用域

事情大概是这样的，有一个大文档，里面引用了某些小文档的id，（我采用的方式是手动引用，mongo其实提供了一种reference方法）我觉得没差就没用。

引用小对象的话，CURD之前先要确定这些小对象存不存在，那就有了如下的过程

func (d *Doc) Foo() {
	obj1 := NewObj1()
	defer obj1.Close()
	obj1.Load(id)
	obj1.Exists()
	
	obj2 := NewObj1()
	defer obj2.Close()
	obj2.Load(id)
	obj2.Exists()
	
}

这当然也没什么问题，但obj1,obj2的声明周期过于长了，在这个过程中，会有三条mongo的连接被使用到，其中两个释放要等到整个函数结束。显然太浪费了。

于是我一抠脚，写出了如下的代码：

func (d *Doc) Foo() {
	{
	obj1 := NewObj1()
	defer obj1.Close()
	obj1.Load(id)
	obj1.Exists()
	}
	
	{
	obj2 := NewObj1()
	defer obj2.Close()
	obj2.Load(id)
	obj2.Exists()
	}
	
}

十秒钟以后，我意识到这是没有任何意义的；因为goalng的defer是注册在函数栈上的，跟作用域没有半毛钱关系，这两个defer照样是在函数返回的时候执行的。

其实到这里，封装成两个函数，缩小一下函数栈就可以达到控制生命周期释放连接的目的；但是老师，我不服，我有看上去更酷炫的写法。

十秒钟以后，这个函数变成了这样

func (d *Doc) Foo() {
	{
	obj1 := NewObj1()
	runtime.SetFinalizer(obj1,func(obj interface{}){
		obj1.Close()
	})
	obj1.Load(id)
	obj1.Exists()
	}
	
	{
	obj2 := NewObj1()
	runtime.SetFinalizer(obj1,func(obj interface{}){
		obj2.Close()
	}
	obj2.Load(id)
	obj2.Exists()
	}
	
}

这样就看上去给力多了是不是！runtime.SetFinalizer会在运行时发现注册对象失去引用的时候调用回调方法。

但是！现实是很残酷的，这段代码其实完全不给力，因为运行时发现对象失去引用是需要一段时间的，这段时间甚至比defer版本更久~

那老师！就没有更给力的了吗。当然有！

func (d *Doc) Foo() {
	{
	obj1 := NewObj1()
	runtime.SetFinalizer(obj1,func(obj interface{}){
		obj1.Close()
	}) 
	obj1.Load(id)
	obj1.Exists()
	}
	runtime.GC()
	
	{
	obj2 := NewObj1()
	runtime.SetFinalizer(obj1,func(obj interface{}){
		obj2.Close()
	}
	obj2.Load(id)
	obj2.Exists()
	}
	
	runtime.GC()
	
}

每当我想要弄死的对象出了作用域，就调用一次强制GC，连接就会毫不犹豫立马释放。

不过最后，我还是为这个Doc实现了小函数来判断引用是否存在；因为这个世界上存在一种行为叫code review，写这种代码会被搞事情的！（逃）

bson.Unmarshal的置空行为

使用这种对象模型，在查询上面很容易地想到就是用自己的引用来反序列化

比如

func (p *Persion)Load(id) {
	p.SessionHelper.Find(...).One(p)
	 
}

这个函数的预期就是把所有字段查询出来，再从bson格式反序列化到p的各个字段。但是，这个mgo下的bson实现有一个我现在还不太理解的动作，会将传入反序列化的实例置为空，而且是无视tag的粗暴的置为空。

也就是说，假设我的结构里面有一些跟数据库字段无关的bson:"-"的辅助字段，用于保存一些计算的结果之类的。

例如：

type Person struct {
	...
	Field string `bson:"-"`
}

mgo这个bson老哥会把我的Field字段置为空。那好气哦。 内部调用的方法就是bson.Unmarshal，具体里面的实现这里就不多说了，代码很好找；这么做原因不懂，提了issue也没人理（好气QAQ）。 没人理的issue

结语

希望mongo官方早日能出自己的驱动！