我与Rails一起使用的常见模式是控制器继承。我将各种共享功能放到基本控制器(ApplicationController或其他一些特定于域/问题的控制器)中，然后从该基本控制器继承以创建单个控制器。
这是我已经做过的或已经看到各种Rails应用程序与控制器继承一起做的一些事情。
可以放置某些类型的共享代码的地方。
将共享的前置/后置过滤器应用于请求。可能使用以下方法修改传入的请求，修改传出的响应或更改请求的流程: before_filter。常见的用例包括身份验证/授权，请求验证和应用程序状态前提条件检查。
为共享基础模板的某些部分的状态/会话相关部分提供共享渲染上下文。过滤器设置一些实例变量，然后基础模板将使用这些实例变量。例如，一个站点具有一个共享头，该头显示当前用户和会话的特定于域的详细信息。
这是我已经做过或看到的各种Django应用程序所做的一些事情。它们与上述内容不太一致，并且我不确定如何以干净的方式进行复制存在一些差距。
我已经看到Django应用程序倾向于更多地使用常规Python函数来封装多种代码重用，并利用python模块进行代码组织。
对于基于函数的Django视图，一种实现前置/后置过滤器的可能方法是使用装饰器，该装饰器有条件地调用基础视图。有没有一种方法可以避免需要将装饰器显式附加到每个视图？
我真的不知道一种处理基本模板上下文的好的通用方法。在某些情况下，如果共享组件相对本地化，则可以使用register.inclusion_tag或其他类似机制将呈现为自定义模板标签的自定义模板用作自定义模板，但是如果上下文相关的内容无法轻松实现，这似乎不是一个好选择被分解为一个组成部分。在其他情况下，如果在任何地方都使用附加上下文，则可以使用中间件将所需状态注入到请求中，但是如果应该将其本地化为例如，这并不是一个好选择。某些路线子集。但是，这些都不像Rails控制器继承那样普遍，尤其是，我不知道一个类似于为基础控制器上的实例变量向基础模板提供其他模板呈现上下文变量的好的解决方案。
在Django中完成上述操作的推荐/惯用方式是什么？诚然，Rails和Django在哲学和体系结构上存在一些差异，因此“等价于X”并不是绝对一对一的。不过，我希望对如何完成这些常用的用例有一些了解。
感谢您阅读本文，并感谢您的见解!
附言:涉及以下几点的相关问答:
Django equivalent to Rails application_controller
python大神给出的解决方案
对于等效的django方法/功能:
可以放置某些类型的共享代码的地方。
如果在视图中，请使用基于类的视图；因为它们就像普通的类一样，所以您可以从它们继承并扩展它们(称为“ mixins”-因为您混合了所需的功能)。
参考:Class Based Views
将共享的前置/后置过滤器应用于请求。潜在地，修改
传入请求，修改传出响应或更改流程
请求，例如before_filter。常见的用例包括
身份验证/授权，请求验证和应用状态
前提条件检查。
有很多方法可以做到这一点。取决于您希望实现的具体程度或通用性:
装饰器(用于基于函数和类的视图)
类继承(用于基于类的视图)
包装器在URL级别起作用(类似于装饰器，但外推到URL映射器)。
中间件(甚至更高级别的抽象)。
为状态/会话相关的部分提供共享的渲染上下文
共享基本模板的一部分，例如过滤器设置一些实例
基本模板随后使用的变量。例如，一个网站有一个
共享标头，其中显示了某些特定于域的详细信息
当前用户和会话。
在django中，template context processors提供了这种模板范围的功能；后者接受请求并返回字典(映射)，然后在所有模板中都可用。