django作为一款功能强大的web应用框架，近年来逐步受到大家的欢迎，越来越多的python开发者投入到django的怀抱中，但是同样由于django中的众多内容，大家在初入django时总会感到有一些『心有余而力不足』，不知道从何处下手。或者在初步了解之后，仍不确定当前方法是否优雅，不知道如何组织项目，以及如何使代码重用性更高。
part 2. 项目架构
好的项目结构是成功的一半。
2.1 整体结构在默认情况下，由django生成的项目结构大概是这样的：
随着项目中的application不停的增加，本地根目录下的package会不停的变多，导致越来越难维护，所以我们要对整个项目有一个清晰的规划，合理的放置各个文件的位置。
如果项目较小，且不打算将其中的application进行各种复用，可以考虑如下方式：
venv文件夹存放项目的virtualenv环境，非必须，可以放置在其他地方。
database这个app专门用于存放model、manage的命令以及模板中用到的一些自定义filters，存放在项目根目录下。
docs和logs分别存放工程的相关文档和运行时产生的log文件。
static存放静态文件，例如css/js/img/font等。
utils存放工程中用到的工具函数、类，以及一些通用的模块，例如logger等。
templates存放模板文件，父模板或被多个模板继承的模板放在根目录，并且以base之类的名称命名，方便维护，其余的模板放在对应的application名字的文件夹中。
web目录存放所有的application，如果有很多的application，可以在此基础上分成更多的package来规划，每个package里存放一类的application。
2.2 model在model模块部分，我们主要关心数据到类的映射，一般情况下，每张表对应的类将放置在单独的文件中，并在models/__init__.py中将对应的类依次导入，这样在其他地方使用时可以通过from database.models import xxxx导入，给类命名时建议添加上项目的名称，例如我这里有个项目的名字是cherry，那么所有的类均为cherryleaks，cherryvulns等，在reivew代码以及编写的过程中会一目了然，知道这个类代表了数据。
建议为models添加单独的manager，并实现相应的方法，以避免进行重复操作。
除此之外，还有一些建议，可以根据实际情况取舍：
不建议使用外键等类型
每张表添加is_deleted，created_time，updated_time字段
善用索引
2.3 view大多数业务逻辑应该放在view部分，此部分应该是最核心的。这里也是推荐将功能相近的view全部放置在同一个文件中。方便未来的维护和开发，该文件应被放置于名为 controller 或 view 的包中。例如处理project相关的路由，全部放置在controller/project.py中。
优先使用django内置的一些view类，例如listview，templateview等，如果需要自己实现view的情况，推荐使用class-based view，将不同的请求方法封装到不同的方法中，方便日后维护。
2.4 template对于模板文件而言，最好的方法就是将不同的页面、功能切割为不同的模板文件，并按applicatio的名称按文件夹存放，这样在后期维护时，可以快速的从每个application找到对应的模板文件。
除此之外，强烈推荐使用模板的继承功能，所有的页面均从父模板继承下来，并且使用各种block来扩充页面，父模板中定义好每个位置的block名称，供子模板覆盖。建议使用通俗简短的名称为每个block命名，例如：sidebar，script，header，main_content，page_title，page_description等。
对于通用的功能，例如评论框，可以考虑单独存放在一个文件中，在需要的地方通过{% include 'filename.tpl.html' %}加载进来。需要注意的是，如果你需要同时使用extends和include指令，一定要在block中使用，否则是无效的。如下例子是无效的：
应当按照如下方式使用：
part 3. 代码风格 3.1 docstringpython语言的灵活性，使得我们有时会在写代码时忘记特定方法的参数类型或返回类型。在此情况下，我们需要使用docstring为每个方法提供清晰的信息标注，以便其他人进行开发和维护。参考这个链接，如果你在使用pycharm，可以编写自动补全docstring。
3.2 多返回值很多情况下，我们的方法需要返回多个值给调用方，或者通过json返回给前端，如果胡乱的返回数据，就会导致开发混乱，到最后根本不知道方法返回了什么东西。
一个比较好的做法就是约定好返回的格式，对于返回给调用方而言，简单的返回tuple即可，并在docstring中写明每个值的含义。除了返回结果，有时我们需要返回一个err，以表明在处理数据过程中是否出现了问题或异常。一般情况下有几种可用的方法：
通过raise抛出异常
通过多返回值返回，例如err, result = func()
通过类中的一个属性返回，例如instance = class(); err = instance.error_message
这三种方法均有利弊，需要根据项目的实际情况来选取，无论使用哪一种方法，都需要在整个项目中保持统一，尽可能的不要混合使用；
对于返回给前端的json，就需要稍微复杂一些，至少要返回2~3个字段：
code是本次调用返回的状态码，根据实际情况自行约定。message 是状态码的易于理解的信息，可供开发人员调试并向用户提供通知。data是实际返回的数据信息，很多时候可以不需要这个字段，具体的字段格式也需要根据实际情况再次进行约定。
part 4. 路由组织 优雅简单的路由保证项目质量，降低维护成本。
4.1 路由系统django有一套强大的路由系统以及路由算法，可以满足业务中的各种需要，并且配置灵活简单，每一个路由配置文件都是url path到function/class的映射。全部都可以自己设置，完全不会受到框架或是其他的一些限制。可以参考文档中关于django请求路由寻找策略的这一部分。
在配置路由中，你可以用尖括号括起来一些变量，便于在后面使用。尖括号里可以用一些路径转换器（path converters）来指定变量类型，例如str, int, slug, uuid, path。一个完整的url路由文件看起来像下面这样：
除此之外，还可以通过re_path在路由中设置正则匹配：
有些时候，你可能希望为一些url添加一个默认路由，例如访问/blog/的时候返回一个默认页面，而访问/blog/page<int:num>的时候返回指定页码的内容，可以通过如下方式配置
4.2 路由包含随着项目的不断扩大，用到的路由也会不断的变多，所以django提供了路由包含的机制，便于我们在不同的app中组织路由。我们来看一个简单的例子：
这个例子中，将所有请求community/*的路由全部交由aggregator.urls去解析，同理，contact/*的请求也全部交给了另外的路由模块去处理；如果你的项目中并没有这么多的application，依然想通过include的方式来管理路由，那么可以采用如下方式：
4.3 命名空间一般情况下，我们的每个django项目都由多个app组成，如果把所有app的路由全部放在urlconf_root里，时间久了这个文件会变的越来越难维护，十分混乱。在不同的app中可能会使用相同名称的路由，导致冲突。为了解决这些问题，我们可以通过使用路由包含和命名空间来解决，特别是如果你在维护一个可以被复用的app，为了保证路由的唯一，命名空间就显得尤为重要了。
命名空间通常有两种：application namespace和instance namespace，例如admin:index表示admin命名空间的index路由。更多关于该部分的内容可以参考：官方文档
application namespace比较好理解，指的是在应用程序层面上的命名空间，一般是如下方式组织的：
instance namespace则指的是实例级别的命名空间，常用于一个app被多次实例化的情况，为了区分每个实例，就需要引入instance namespace。我们使用官方文档中的例子看一下：
可以看到两个路由author-polls和publisher-polls其实都包含了相同的路由，但是指定了不同的命名空间，这就是instance级别的命名空间，即当前正在访问的对象的命名空间。不同的用户身份访问不同的url，会得到不同的命名空间，例如游客和管理员均访问polls:index所指向的页面，但是由于命名空间的不同，会得到完全不同的结果。
以上就是django开发方法是什么的详细内容。