按照我对 SQLAlchemy 的理解,其实它的定位大概相似于:sql
然而 Core 部分基本没有人使用。并且它对使用者暴露了太多 API,这无疑加剧了使用者的心智负担,可谓之「不友好」。另外,其官方文档也有点稍显杂乱,让初学者抓不住轻重。chrome
SQLAlchemy 使用最多的地方,大概就是与 Flask 的结合了,即 Flask-SQLAlchemy。这就是 SQLAlchemy 的 Wrapper,固然若是咱们没有使用 Flask,那么就须要本身封装一层 Wrapper 了,或者使用别人已经弄好的 Wrapper。bash
至于为何,如上文所述,SQLAlchemy给使用暴露的API太多,让人感到无所适从(不过若是使用得熟练了,他仍是很顺手的)。session
定义完 Model 以后,立刻咱们就到了业务逻辑这个层次了。app
没有会把一个 Model 导入到 Controller 层使用,封装一个 Manager 层是必须的( 若是必要,视业务逻辑复杂性,还可引入更多的层次)。工具
好比(以 Flask 为例)ui
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。google
增删该查是每个 Model 都会具备的操做,若是每一个 Manager 中都写一大堆重复的create_xxx, get_xxx
,那很明显咱们是在Repeat Yourself
。spa
首先咱们会想到使用继承来解决,定义一个 BaseManager 基类,而后你们都继承它,整个过程都很符合继承的思惟直觉。不过我比较偏好写各类 Utils 来解决,把通用的不变的逻辑放到 Utils 中,而后各个 Manager 将操做转发到 Utils 中。code
好比:
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)
复制代码
我是一个 Django 党,我对 Django 印象最深入的就是它的 ORM 了,功能完善并且十分强大。可是对 SQLAlchemy 来讲,如前文所述,它只不过是一款 Library,天然没有 Migration 工具。
可是其做者本身也写了对应的 migration 库,没有和 SQLAlchemy 整合到一块儿(你们能够Google下)。总的来讲,还凑合,可堪一用(天然不能和Django的migration比)。