由于revel框架本身对于model层的编写没有提供任何指导,所以在设计这部分的时候就有些犹豫,反复斟酌到底怎样才算是最佳实践。
我在做山坡网的时候刚开始也纠结了一下,拿不准mongodb的session的创建和销毁应该在什么地方处理。直到有一天看到了revmgo的作者在与revel的作者讨论(具体内容在这里),就去研究了下revmgo,之后立即就用它替换了我自己的实现。
先说下用法吧。
revmgo.dial = mongodb://username:password@serverip/database
func init() {
revmgo.ControllerInit()revel.OnAppStart(func() {
revmgo.AppInit()
}
}
type Application struct {
*revel.Controller
revmgo.MongoController
}
这里有个小插曲,revmgo.MongoController已经内嵌过revel.Controller了,但此处还是不能省略*revel.Controller。原因是revel在确定有效的controller的action的时候只反射了一层,跟revel的作者讨论过这个问题,后来他说服我了,原因是如果不断递归反射的话复杂度会变高而且性能损失会不可控。好吧,其实这也算是OO的遗毒。看起来挺难受,多写了一行代码,设计上也不太舒服,但仔细想来对性能和整体的复杂度却都有好处,既然如此,何必执着设计上的完美呢?简单就是美。
//Data access layer
type Dal struct {
session *mgo.Session
}//创建新的Dal
func NewDal(session *mgo.Session) *Dal {
if session == nil {
panic("session cannot be nil.")
}
return &Dal{session}
}
现在来看看在controller中如何使用。
func (c *Account) HandleRegister(user *models.MockUser) revel.Result {
//Validate parameter here.
dal := models.NewDal(c.MongoSession)
err := dal.RegisterUser(user)
//Biz logic here
}
revmgo的内部实现非常简单,整个代码也就110行,基本可以一目了然。
总的来说,调用revmgo.AppInit()的时候读取app.conf中的配置,可以看到有两个配置项有效,"revmgo.dial"为连接字符串,"db.spec"确定mongodb的session的重复利用方式(具体含义参考这里),然后建立session。
之后的revmgo.ControllerInit注册了两个interceptfunc,用于在controller的action访问前后建立和关闭session。
func ControllerInit() {
revel.InterceptMethod((*MongoController).Begin, revel.BEFORE)
revel.InterceptMethod((*MongoController).End, revel.FINALLY)
}
其实我对于这个设计颇有微词,ControllerInit的存在简直就是对revel的module设计机制的嘲笑,很难相信作为一个模块竟然还需要使用者手动调用初始化函数。这个部分应该不难处理,常规来说只应该让使用者注册需要使用的module和执行顺序,初始化和解构都由module管理器负责。跟revel的作者也讨论了这个问题,看他似乎有别的设计意图,等等看revel 1.0正式发布时会是什么样子吧。