简单的django PROJECT结构及运作机理

>>> django PROJECT直观上是一个动态网站，其实可以理解为一个app的容器。

┌ Project\
│
├──┬ mysite\
│　 ├── manage.py　　　　＃管理引擎，用于启动服务器、检查程序、同步数据库等
│　 └─┬ mysite\
│　 　 ├── __init__.py
│ 　　├── settings.py　　＃用于管理网站的所有配置，包括数据库，资源及app安装等
│ 　　├── urls.py　　　　＃url/服务路由，管理某个url调用app下面的服务
│ 　　└── wsgi.py # Python Web Server Gateway Interface 底层工具集配置
│
├──┬ app1\
│ 　 ├── __init__.py
│ 　├── models.py　　＃app1 的数据模型，映射数据库结构
│ 　 ├── views.py　　　＃定义app services，由URL调用的app1 服务
│ 　 └── tests.py
│
├──┬ app2\
│ 　 ├── __init__.py
│ 　├── models.py　　＃app2 的数据模型，映射数据库结构
│　 ├── views.py　　　＃定义app services，由URL调用的app2 服务
│　 ├── tests.py
│　 │　 #app2使用的包package1和package2
│　 ├─┬ package1\
│　 │　├── __init__.py
│　 │　└── module1.py
│　 │
│　 └─┬ package2\
│ 　 ├── __init__.py
│ 　 ├── module2.py
│　 └── module3.py
│
│　　　 　＃下面为可配置目录
├─── templates\　　　　＃html 模版地址，在settings.py的TEMPLATE_DIRS配置
├─── database\　　　　 ＃数据库地址，在settings.py的DATABASES下的‘names’配置
└─── media\　　　　　 ＃资源地址，在settings.py的MEDIA_ROOT配置

>>> 整个project通过DevServer的运作流程：

1. 进入Project\mysite\ 然后在命令行运行 python manage.py runserver
-> 加载 mysite\settings.py以及的mysite\urls.py设置（由于是用DevServer所以和wsgi.py没什么关系）
2. 发起url请求
-> 经mysite\urls.py 路由访问到正确的app.views.service，如app1.views.svc1()
-> 由app1.views.svc1() 调用models.py里面的class的某个实例，如app1.models.class1
-> 访问由app1.models.class1 的实例封装的数据。
-> 获得数据后，由app1.views.svc1() 生产content，如c
-> 通过Template机制用一个html template t渲染content，如 t.render(c)
-> url请求最终获得t.render(c) 后的页面。

注意：

>>> mysite\目录下面是没有views.py这个文件的，而是分布在各个app目录下，这是因为project主体mysite不是业务逻辑的承载者，而是业务逻辑的组织者。所有业务逻辑相关的服务都应该以app的形式在各自的views下进行封装。另一方面，mysite和apps在目录结构上是同级的，以强调app的可插拔性，即app是绝对独立的，app内任何内容都不应该依赖于project的其他结构存在。