摘要：默認(rèn)對(duì)此沒有很好的支持?jǐn)?shù)據(jù)庫結(jié)構(gòu)是由另一個(gè)工具管理的，并沒有直接修改數(shù)據(jù)庫結(jié)構(gòu)的權(quán)限。第二個(gè)思路是利用的多數(shù)據(jù)庫支持。由于使用后臺(tái)的用戶基本上只有公司內(nèi)部的業(yè)務(wù)人員，數(shù)據(jù)量不會(huì)大，用服務(wù)器級(jí)的數(shù)據(jù)庫有牛刀之嫌。

在多數(shù)項(xiàng)目中，總有一些幾乎一成不變的 CRUD 操作，編寫這些代碼很無聊，但又是整個(gè)系統(tǒng)必不可少的功能之一。我們?cè)谏弦粋€(gè)項(xiàng)目中也面臨類似的問題，雖然已經(jīng)實(shí)現(xiàn)了一個(gè)功能相對(duì)完整的管理后臺(tái)，也盡量做到了代碼復(fù)用，但隨著項(xiàng)目規(guī)模的增長，需要編寫的樣本代碼也不斷膨脹，占用了大量開發(fā)時(shí)間。

面對(duì)這種局面，我自然想到了 Django。要知道， Django Admin 幾乎就是為這種需求量身定制的。但對(duì)于我們的項(xiàng)目而言，還有幾個(gè)問題要解決：

我們的數(shù)據(jù)庫使用 SQL Server。Django 默認(rèn)對(duì)此沒有很好的支持；

數(shù)據(jù)庫結(jié)構(gòu)是由另一個(gè)工具管理的，Django 并沒有直接修改數(shù)據(jù)庫結(jié)構(gòu)的權(quán)限。因*

此，我們不能使用 Django migrate；

出于同樣的理由，我們無法在數(shù)據(jù)庫中創(chuàng)建 Django Admin 內(nèi)置要求的數(shù)據(jù)表（包括 auth/session 等）。
下面我們來解決這些問題。如果你碰到類似情況的話，可以參考本文的做法。

遺憾的是，針對(duì) Django 開發(fā)的 SQL Server 適配器雖然有幾種，但都比較古老了，對(duì)新版的 Django 支持存在問題。經(jīng)過嘗試，我們選擇了?Django-Mssql，雖然功能是可用的，但該庫只支持到 Django 1.8，經(jīng)測試，對(duì) Django 1.11 不兼容，Django 2.x 就更不行了。好在我們并不需要很新的功能，因此就用 virtualenv 鎖定版本了：

Django==1.8
django-mssql==1.8
pywin32==223

??在這里還是要推薦下我自己建的Python開發(fā)學(xué)習(xí)群：725479218，群里都是學(xué)Python開發(fā)的，如果你正在學(xué)習(xí)Python ，小編歡迎你加入,大家都是軟件開發(fā)黨，不定期分享干貨（只有Python軟件開發(fā)相關(guān)的），包括我自己整理的一份2018最新的Python進(jìn)階資料和高級(jí)開發(fā)教程，歡迎進(jìn)階中和進(jìn)想深入Python的小伙伴
django-mssql 是 Windows 版的庫，幕后使用了 ADO 為驅(qū)動(dòng)，因此同時(shí)還要安裝 pywin32。

針對(duì)第二和第三個(gè)問題基本上有兩個(gè)思路。第一個(gè)是通過實(shí)現(xiàn)自定義的 Backend 來跳過 Django 內(nèi)置的、基于數(shù)據(jù)庫的實(shí)現(xiàn)。從原理上來講是行得通的，但簡單嘗試了一下，發(fā)現(xiàn)要自定義的部分相當(dāng)多，工作量太大。總之，這條路不是很可取。

第二個(gè)思路是利用 Django 的多數(shù)據(jù)庫支持。既然業(yè)務(wù)數(shù)據(jù)庫不可由 Django 來管理，那么就再用一個(gè)數(shù)據(jù)庫來支持 Django 的基本功能，而 Django 對(duì)業(yè)務(wù)數(shù)據(jù)庫只作查詢和更新，不執(zhí)行 migrate。當(dāng)然，為了使用多個(gè)數(shù)據(jù)庫，我們需要在配置上多做一些工作。由于使用后臺(tái)的用戶基本上只有公司內(nèi)部的業(yè)務(wù)人員，數(shù)據(jù)量不會(huì)大，用服務(wù)器級(jí)的數(shù)據(jù)庫有牛刀之嫌。處于簡便考慮，這里使用默認(rèn)的 SQLite 作為內(nèi)置數(shù)據(jù)庫：

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": os.path.join(BASE_DIR, "db.sqlite3"),
    },
    "mydb": {
        "ENGINE": "sqlserver_ado",
        "HOST": "127.0.0.1",
        "NAME": "",
        "USER": "",
        "PASSWORD": "",
        "OPTIONS": {
            "provider": "SQLOLEDB",
        }
    }
}

需要說明，Django-mssql 為 provider 選項(xiàng)提供的默認(rèn)值（按照官方文檔應(yīng)為 SQLCLI10）實(shí)測會(huì)導(dǎo)致出現(xiàn)“找不到提供程序” 的錯(cuò)誤。由于 provider 的設(shè)置取決于 ADO 的注冊(cè)信息，不一定在所有機(jī)器上都相同，所以你可能需要自己測試決定哪個(gè)選項(xiàng)可用。

現(xiàn)在我們配置了兩個(gè)數(shù)據(jù)源，但還需要告訴 Django 它們和模型的對(duì)照關(guān)系。實(shí)現(xiàn)這一點(diǎn)可以在語句/實(shí)體/全局等多種級(jí)別定義。對(duì)于我們的需求而言，對(duì)應(yīng)關(guān)系是固定的，逐個(gè)模型定義并無必要，通過全局定義是最簡單的。實(shí)現(xiàn)這一定義的對(duì)象在 Django 的術(shù)語中稱為數(shù)據(jù)庫路由（Database Router）。首先在 settings.py 中定義類名：

DATABASE_ROUTERS = ["project.db.MyAppRouter"]

然后完成類的實(shí)現(xiàn)：

class MyAppRouter:
    def db_for_read(self, model, **hints):
        if model._meta.app_label == "myapp":
            return "myapp"
        return None

    def db_for_write(self, model, **hints):
        if model._meta.app_label == "myapp":
            return "myapp"
        return None

    def allow_relation(self, obj1, obj2, **hints):
        return None

    def allow_migrate(self, db, app_label, model_name=None, **hints):
        return False

數(shù)據(jù)路由需要按照 Django 的要求實(shí)現(xiàn)四個(gè)方法。其中主要是讀寫兩個(gè)方法，我們需要根據(jù)傳來的模型決定匹配到哪個(gè)數(shù)據(jù)源。 其他兩個(gè)方法目前意義不大，按照默認(rèn)的實(shí)現(xiàn)即可。

配置到此完成，接下來需要?jiǎng)?chuàng)建模型。對(duì)于已經(jīng)存在的數(shù)據(jù)表，可以用管理命令 inspectdb 反向生成代碼，減少一些手工輸入的負(fù)擔(dān)。但生成的代碼未必完全符合你的要求，所以還是應(yīng)該自己檢查一下。對(duì)于 SQL Server，如果主鍵名不是默認(rèn)的 id，那么 inspectdb 似乎不會(huì)自動(dòng)識(shí)別到它們，所以我們需要檢查一下主鍵字段有無 primary_key，如果沒有的話就加上。

python manage.py inspectdb --database=myapp > myappmodels.py

為了方便調(diào)試和辨別記錄，一般來說我們還要為模型類加上 verbose_name 并重載內(nèi)置的字符串方法。

class XXModel(models.Model):
    XXId = models.BigIntegerField(primary_key=True)
    ...

    class Meta:
        managed = False
        db_table = "XXModel"
        verbose_name = "模型名稱"
        verbose_name_plural = "模型名稱"

    def __str__(self):
        return self.XXField

把模型添加到 admin，對(duì)應(yīng)的后臺(tái)管理信息就完成了。

admin.site.register(XXModel, XXAdmin)

最后，為內(nèi)置數(shù)據(jù)庫生成必要的表，創(chuàng)建管理員賬戶，即可運(yùn)行程序。以下命令就無需說明了：

$ python manage.py migrate
$ python manage.py createsuperuser
$ python manage.py runserver

我們第一個(gè)版本的后臺(tái)程序是自己手工編碼完成的，用了大概兩周的時(shí)間。問題在于，每增加一個(gè)模型都要手工添加大量樣本代碼。而改寫成 Django 只用了一天時(shí)間，包括熟悉相關(guān)資料和使用方法，增加一個(gè)模型只需花幾分鐘。這也是為什么很多了解 Django 的開發(fā)者轉(zhuǎn)移到其他平臺(tái)以后，會(huì)尋找類似的項(xiàng)目。就我了解的范圍，Spring Boo 和 Django 在概念上比較類似，但 Boo 主要走的是代碼生成的路線，復(fù)雜度更高，理論上靈活性也應(yīng)該更好一些（我沒有深度研究過）。Nodejs 社區(qū)有 Keystone.js 和 Sails.js，不過前者專門針對(duì) MongoDB，后者支持多種數(shù)據(jù)庫后端，但風(fēng)聞最近有停止開發(fā)的跡象。.Net 社區(qū)以前有一個(gè) DynamicData，現(xiàn)在似乎也沒了下文。發(fā)展多年的 Django 也應(yīng)該算是同類產(chǎn)品中最成熟、生態(tài)也最為完整的產(chǎn)品了。

Django 潛在的問題在于不夠現(xiàn)代化的界面，以及深度定制較為困難。不過對(duì)于我們的后臺(tái)應(yīng)用來說，這些都是可以接受的代價(jià)。