SQLAlchemy 最佳實踐

按照我對 sqlalchemy 的理解，其實它的定位大概類似於：

一款比較偏底層 orm lib

提供了一些基礎了 orm 功能，包括 sqlalchemy core 和 sqlalchemy orm

然而 core 部分基本沒有人使用。而且它對使用者暴露了太多 api，這無疑加重了使用者的心智負擔，可謂之「不友好」。另外，其官方文件也有點稍顯雜亂，讓初學者抓不住輕重。

至於為什麼，如上文所述，sqlalchemy給使用暴露的api太多，讓人感到無所適從（不過如果使用得熟練了，他還是很順手的）。

定義完 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。

增刪該查是每乙個 model 都會具有的操作，如果每個 manager 中都寫一大堆重複的create_***, get_***，那很明顯我們是在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)
複製**

我是乙個 django 黨，我對 django 印象最深刻的就是它的 orm 了，功能完善而且十分強大。但是對 sqlalchemy 來說，如前文所述，它只不過是一款 library，自然沒有 migration 工具。

但是其作者自己也寫了對應的 migration 庫，沒有和 sqlalchemy 整合到一起（大家可以google下）。總的來說，還湊合，可堪一用（自然不能和django的migration比）。

SQLAlchemy 最佳實踐

最佳實踐 Flutter 最佳實踐

JUnit最佳實踐

SVN最佳實踐

SQLAlchemy 最佳實踐

最佳實踐 Flutter 最佳實踐

JUnit最佳實踐

SVN最佳實踐

相關推薦