问题

在多数项目中,总有一些几乎一成不变的 CRUD 操作,编写这些代码很无聊,但又是整个系统必不可少的功能之一。我们在上一个项目中也面临类似的问题,虽然已经实现了一个功能相对完整的管理后台,也尽量做到了代码复用,但随着项目规模的增长,需要编写的样本代码也不断膨胀,占用了大量开发时间。

面对这种局面,我自然想到了 Django。要知道, Django Admin 几乎就是为这种需求量身定制的。但对于我们的项目而言,还有几个问题要解决:

  • 我们的数据库使用 SQL Server。Django 默认对此没有很好的支持;
  • 数据库结构是由另一个工具管理的,Django 并没有直接修改数据库结构的权限。因此,我们不能使用 Django migrate;
  • 出于同样的理由,我们无法在数据库中创建 Django Admin 内置要求的数据表(包括 auth/session 等)。

下面我们来解决这些问题。如果你碰到类似情况的话,可以参考本文的做法。

SQL Server 支持

遗憾的是,针对 Django 开发的 SQL Server 适配器虽然有几种,但都比较古老了,对新版的 Django 支持存在问题。经过尝试,我们选择了 Django-Mssql,虽然功能是可用的,但该库只支持到 Django 1.8,经测试,对 Django 1.11 不兼容,Django 2.x 就更不行了。好在我们并不需要很新的功能,因此就用 virtualenv 锁定版本了:

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

django-mssql 是 Windows 版的库,幕后使用了 ADO 为驱动,因此同时还要安装 pywin32。

多数据库

针对第二和第三个问题基本上有两个思路。第一个是通过实现自定义的 Backend 来跳过 Django 内置的、基于数据库的实现。从原理上来讲是行得通的,但简单尝试了一下,发现要自定义的部分相当多,工作量太大。总之,这条路不是很可取。

第二个思路是利用 Django 的多数据库支持。既然业务数据库不可由 Django 来管理,那么就再用一个数据库来支持 Django 的基本功能,而 Django 对业务数据库只作查询和更新,不执行 migrate。当然,为了使用多个数据库,我们需要在配置上多做一些工作。由于使用后台的用户基本上只有公司内部的业务人员,数据量不会大,用服务器级的数据库有牛刀之嫌。处于简便考虑,这里使用默认的 SQLite 作为内置数据库:

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': '<DB_NAME>',
        'USER': '<DB_USER>',
        'PASSWORD': '<DB_PASSWORD>',
        'OPTIONS': {
            'provider': 'SQLOLEDB',
        }
    }
}

需要说明,Django-mssql 为 provider 选项提供的默认值(按照官方文档应为 SQLCLI10)实测会导致出现“找不到提供程序” 的错误。由于 provider 的设置取决于 ADO 的注册信息,不一定在所有机器上都相同,所以你可能需要自己测试决定哪个选项可用。

现在我们配置了两个数据源,但还需要告诉 Django 它们和模型的对照关系。实现这一点可以在语句/实体/全局等多种级别定义。对于我们的需求而言,对应关系是固定的,逐个模型定义并无必要,通过全局定义是最简单的。实现这一定义的对象在 Django 的术语中称为数据库路由(Database Router)。首先在 settings.py 中定义类名:

DATABASE_ROUTERS = ['project.db.MyAppRouter']

然后完成类的实现:

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

数据路由需要按照 Django 的要求实现四个方法。其中主要是读写两个方法,我们需要根据传来的模型决定匹配到哪个数据源。 其他两个方法目前意义不大,按照默认的实现即可。

定义模型

配置到此完成,接下来需要创建模型。对于已经存在的数据表,可以用管理命令 inspectdb 反向生成代码,减少一些手工输入的负担。但生成的代码未必完全符合你的要求,所以还是应该自己检查一下。对于 SQL Server,如果主键名不是默认的 id,那么 inspectdb 似乎不会自动识别到它们,所以我们需要检查一下主键字段有无 primary_key,如果没有的话就加上。

python manage.py inspectdb --database=myapp > myapp\models.py

为了方便调试和辨别记录,一般来说我们还要为模型类加上 verbose_name 并重载内置的字符串方法。

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,对应的后台管理信息就完成了。

admin.site.register(XXModel, XXAdmin)

运行程序

最后,为内置数据库生成必要的表,创建管理员账户,即可运行程序。以下命令就无需说明了:

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

总结

我们第一个版本的后台程序是自己手工编码完成的,用了大概两周的时间。问题在于,每增加一个模型都要手工添加大量样本代码。而改写成 Django 只用了一天时间,包括熟悉相关资料和使用方法,增加一个模型只需花几分钟。这也是为什么很多了解 Django 的开发者转移到其他平台以后,会寻找类似的项目。就我了解的范围,Spring Boo 和 Django 在概念上比较类似,但 Boo 主要走的是代码生成的路线,复杂度更高,理论上灵活性也应该更好一些(我没有深度研究过)。Nodejs 社区有 Keystone.js 和 Sails.js,不过前者专门针对 MongoDB,后者支持多种数据库后端,但风闻最近有停止开发的迹象。.Net 社区以前有一个 DynamicData,现在似乎也没了下文。发展多年的 Django 也应该算是同类产品中最成熟、生态也最为完整的产品了。

Django 潜在的问题在于不够现代化的界面,以及深度定制较为困难。不过对于我们的后台应用来说,这些都是可以接受的代价。

参考资料: