文章预览
尽量使用其 Wrapper
按照我对 SQLAlchemy 的理解,其实它的定位大概类似于:
- 一款比较偏底层 ORM lib
- 提供了一些基础了 ORM 功能,包括 SQLAlchemy Core 和 SQLAlchemy ORM
然而 Core 部分基本没有人使用。而且它对使用者暴露了太多 API,这无疑加重了使用者的心智负担,可谓之「不友好」。另外,其官方文档也有点稍显杂乱,让初学者抓不住轻重。
SQLAlchemy 使用最多的地方,大概就是与 Flask 的结合了,即 Flask-SQLAlchemy。这就是 SQLAlchemy 的 Wrapper,当然如果我们没有使用 Flask,那么就需要自己封装一层 Wrapper 了,或者使用别人已经弄好的 Wrapper。
至于为什么,如上文所述,SQLAlchemy给使用暴露的API太多,让人感到无所适从(不过如果使用得熟练了,他还是很顺手的)。
Model 之上再封装一层 Model Manager
定义完 Model 之后,马上我们就到了业务逻辑这个层次了。
没有会把一个 Model 导入到 Controller 层使用,封装一个 Manager 层是必须的( 如果必要,视业务逻辑复杂性,还可引入更多的层次)。
比如(以 Flask 为例)
user_mgr.py
from SomeWhere import db
from models import User
class UserMgr:
@classmethod
def create_user(cls, **kw):
u = User(**kw)
db.session.add(u)
db.session.commit()
return u
@classmethod
def get_user(cls, **kw):
return User.query.filter_by(**kw).first()
上层如果要操作 User,则只通过 UserMgr。
包装一个 OrmUtils
增删该查是每一个 Model 都会具有的操作,如果每个 Manager 中都写一大堆重复的create_xxx, get_xxx
,那很明显我们是在Repeat Yourself
。
首先我们会想到使用继承来解决,定义一个 BaseManager 基类,然后大家都继承它,整个过程都很符合继承的思维直觉。不过我比较偏好写各种 Utils 来解决,把通用的不变的逻辑放到 Utils 中,然后各个 Manager 将操作转发到 Utils 中。
比如:
utils/orm.py
from SomeWhere import db
class OrmUtils:
@classmethod
def create_orm(cls, orm_cls, **kw):
orm = orm_cls(**kw)
db.session.add(orm)
db.session.commit()
return orm
@classmethod
def get_orm(cls, orm_cls, **kw):
return orm_cls.query.filter_by(**kw).first()
@classmethod
def delete_orm(cls, orm):
orm.delete()
db.session.commit()
return True
user_mgr.py
class UserMgr:
@classmethod
def create_user(cls, **kw):
return OrmUtils.create_orm(User, **kw)
使用一款 migration 工具
我是一个 Django 党,我对 Django 印象最深刻的就是它的 ORM 了,功能完善而且十分强大。但是对 SQLAlchemy 来说,如前文所述,它只不过是一款 Library,自然没有 Migration 工具。
但是其作者自己也写了对应的 migration 库,没有和 SQLAlchemy 整合到一起(大家可以Google下)。总的来说,还凑合,可堪一用(自然不能和Django的migration比)。
附录
………………………………