在多数项目中，总有一些几乎一成不变的 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 在这里还是要推荐下我自己建的Python开发学习群：725479218，群里都是学Python开发的，如果你正在学习Python ，小编欢迎你加入,大家都是软件开发党，不定期分享干货（只有Python软件开发相关的），包括我自己整理的一份2018最新的Python进阶资料和高级开发教程，欢迎进阶中和进想深入Python的小伙伴
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 潜在的问题在于不够现代化的界面，以及深度定制较为困难。不过对于我们的后台应用来说，这些都是可以接受的代价。
原文地址：http://blog.51cto.com/13786054/2130762