Django风格指南
Django风格指南，给Django使用者的一些关于目录结构、使用的建议。该指南中所有的例子你都可以在DeerU(https://github.com/gojuukaze/DeerU)项目中找到。
project结构
project结构建议是这样的（demo）
1 app1/ 2 ... 3 app2/ 4 ... 5 html_app/ 6 ... 7 project_name/ 8 ... 9 tool/ 10 ... 11
app1，app2，project_name三个目录是标准的django目录结构，除此之外多了html_app与tool。
html_app：这是用来专门存放前端代码的目录，虽然你可以把前端代码放到不同的app中，但更加建议你单独放在前端专属的app中，在此app中用不同的目录来区分不同app的前端代码。tool： 用来存放一些每个app都会用到的公用函数，比如：时间处理函数，Exception类等
子project目录结构
项目下的project_name目录建议是这样的（demo）
demo中并没有严格按照这个目录结构，因为demo需要支持git升级且不影响已修改的settings配置。
在实际项目中这个结构不一定适用于所有项目，但也有可以借鉴的地方。
1# * 表示不提交到仓库 2 3project_name/ 4 * settings.py 5 settings_common.py 6 settings_dev.py 7 settings_test.py 8 settings_project.py 9 * settings_local.py 10
-
settings_common.py： 建议首先需要一个settings_common.py，它用来保存一些在dev、test、product三个环境用到公用的配置。 -
settings.py：Django的settings文件，之所以不建议提交是为了防止把开发时的修改提交了上去，造成bug。在实际上线时根据不同环境把不同环境的settings文件拷贝为settings.py -
settings_dev.py：dev环境的专有配置，比如数据库地址、密码，缓存地址等，它里面引用了settings_common，如：from xxx.settings_common import * -
settings_local.py：这个用于本地开发的settings，因为开发时会对settings配置进行修改，建议此文件不提交代码仓库，防止对其他人的开发造成干扰。
app结构
初始、小型的项目app
对于初始、小型的项目app结构建议是这样的
1app_name\ 2 apps.py 3 admin.py 4 consts.py 5 models.py 6 db_managers.py 7 managers.py 8 urls.py 9 views.py 10 class_viws.py 11
-
consts.py： 保存一些app内的全局变量 -
views.py：存放函数view -
class_viws.py：存放class view -
db_managers.py： 存放每个model的纯数据库操作函数，定义model后应在db_managers.py中加入该model的基本db操作函数，在view中不应有xx.objects.xx这样的操作。比如（demo）：1########### User ############ 2 3def create_user(name, age): 4 return User.objects.create(name=name, age=age) 5 6def get_user_by_id(id): 7 try: 8 return User.objects.get(id=id) 9 except: 10 return None 11 12def get_user_by_id_with_lock(id): 13 try: 14 return User.objects.select_for_update().get(id=id) 15 except: 16 return None 17 18def get_all_user(): 19 return User.objects.all() 20 21def filter_user_by_age(age): 22 return User.objects.filter(age=age) 23 24def filter_user_by_age_and_name(age, name): 25 return User.objects.filter(age=age, name=name) 26 27def delete_user_by_id(id): 28 return User.objects.delete(id=id) 29 30# 在函数中进行进一步处理，这个根据喜好 31def filter_user_order_by_age(): 32 return User.objects.filter().order_by('age') 33-
函数命名为
动词+model名+by 条件+with 其他操作；动词一般就是objects后面跟的方法 -
对于
get操作建议返回查询值或者None，而不是抛错。 -
对于
filter操作建议直接返回QuerySet，方便外部对结果进行进一步操作，比如:count、odder。 -
对于
filter的结果很多时候你需要进一步处理，你可以直接用filter函数的返回结果进行处理，或者像filter_user_order_by_age()一样直接把它封装成一个函数，这个根据个人偏好选择。1users = get_all_user().order_by('age') 2# or 3users = filter_user_order_by_age() -
一般来说这里面的函数只是单纯的db操作，不应有太多的逻辑。
-
-
managers.py：存放model相关的逻辑处理函数，功能类函数，以及一些该app专用的函数，比如：1######### user ########### 2 3def login_user(name, passwd): 4 user = get_user_by_name(name=name) 5 if not user: 6 return False 7 return login_user(user, passwd) 8 9def add_user(name, age): 10 user = get_user_by_name(name) 11 if user: 12 return None, "存在相同name" 13 return create_user(name, age), "" 14 15def get_online_user(): 16 online_user=[] 17 users=get_all_user() 18 for u in users: 19 if is_ online(u): 20 online_user.append(u) 21 return online_user 22
中型项目app结构
随着项目不断迭代，功能增加后，单个views.py文件可能无法放下所有代码，这时你需要对app进行进一步的分层（demo）
1# demo中对models也进行了拆分，之后会讲到 2 3app_name\ 4 apps.py 5 admin.py 6 consts.py 7 models.py 8 db_managers\ 9 user_managers.py 10 xx_managers.py 11 managers\ 12 user_managers.py 13 xx_managers.py 14 urls\ 15 __init__.py 16 # 根据版本划分 17 v1_urls.py 18 v2_urls.py 19 20 # 根据功能，model划分 21 user_urls.py 22 views\ 23 # 根据版本划分 24 v1_views.py 25 v2_views.py 26 v1_class_viws.py 27 28 # 根据功能，model划分 29 user_views.py 30 user_class_views.py 31
可以看到该结构主要对views、urls、managers、db_managers建立了单独的文件夹。
结合实际情况，根据model，功能，版本把单个文件py文件拆分为多个。
-
对于urls目录，注意它的
__init__.py很重要，它里面include了其他的子urls文件，如（demo）：1urlpatterns = [ 2 path('v1/', include('app_name.urls.v1_urls')), 3 path('v2/', include('app_name.urls.v2_urls')), 4 5 path('user/', include('app_name.urls.user_urls')), 6 7]在项目的入口
project_name/urls.py中这样include app的url：1urlpatterns = [ 2 path('app_name/', include('app_name.urls')),, 3 4]这样做可以防止每次新增url文件都修改项目的
urls.py
中大型项目app目录结构
项目再次扩展，单个models.py文件无法放下所有model了，这时需要对models.py文件进行拆分，新的结构如下（demo）:
1app_name\ 2 apps.py 3 admin.py 4 consts.py 5 models.py 6 app_models\ 7 user_models.py 8 xx_models.py 9 db_managers\ 10 managers\ 11 urls\ 12 views\ 13
根据实际情况把models.py分成多个子model，建议在这次拆分model时充分考虑所有的情况，重点思考这样拆分是否可以做的model之间的解耦。
-
大家可能注意到，
models.py文件并没有删除，因为这个django的默认model位置，在models.py中这样把其他model引入（demo）：1from app_name.app_models.user_model import * 2from app_name.app_models.xxx_model import * 3在子model文件中把每个model加到
__all__中（demo）：1# user_models.py 2 3__all__ = ['User', 'UserGroup',] 4 5class User(models. Model): 6 pass 7 8class UserGroup(models. Model): 9 pass需要用到model时你应该从子model文件import（demo）：
1from app_name.app_models.user_models import User 2 3user = User.objects.get(id=1)
大型项目app结构
发展到大型项目时，单个app已经无法放下所有文件了，应该根据实际情况把一些model、功能单独拿出来作为一个新的app。如果在中大型项目时拆分足够好，那么把代码放到一个新的app会很轻松，因此中大型项目的app结构拆分十分重要。
html_app结构
1html_app\ 2 apps.py 3 templates\ 4 # 根据app划分 5 app1_templates\ 6 app1_html.html 7 8 # 根据model、功能划分 9 user_templates\ 10 get_user_html.html 11 create_user_html.html 12 static\ 13 app1_static\ 14 css\ 15 js\ 16 user_static\ 17 css\ 18 js\ 19 20 # or 21 22 css\ 23 app1_css\ 24 user_css\ 25 js\ 26 app1_js\ 27 user_js\ 28
根据实际情况对templates，static目录的结构进行划分，这里没有什么标准建议 ，具体问题具体分析。
view命名
view函数、类命名应该以view结尾，方便与其他镜像区分函数，如：
1def create_user_view(request): 2 pass 3 4def get_user_view(request): 5 pass 6 7class UserListView(ListView): 8 pass
model导入
导入model时建议直接导入model，而不是导入model所在的py文件，如：
1# 不建议这样做 2# from app_name import models 3 4from app_name.models import User, UserGroup
这样如果对model进行删除、迁移可以很快的发现错误。
html中引入静态文件
在html中应使用软连接引入静态文件，如（demo）：
1{% load static %} 2<link href="{% static '/app_name/css/base_theme.css' %}" type="text/css"/> 3<script defer src="{% static '/base_theme/js/fontawesome.js' %}"></script>
为了保证引入静态文件成功，你应该正确的配置settings.py文件，具体可以参考官方文档。
正确导入settings
需要使用settings中的配置，你应该这样import：
1from django.conf import settings 2 3settings.xxx
是否提交migrations文件
提交migrations可以方便的管理数据库的表，为新表增加默认值。但如果开发时，把一些临时的、不完善的migrations文件提交上去有可能对数据库造成不可逆的修改。
因此一些项目中选择不提交migrations文件，上线时在服务器上生成migrations文件。
这个问题同样需要根据实际情况决定，但如果你选择提交，那要注意提交的migrations文件一定是经过测试的。