导读：本篇文章首席CTO笔记来给大家介绍有关django装饰器可以用来做什么的相关内容，希望对大家有所帮助，一起来看看吧。
Django--快速实现用户登录
我们在系统开发时都会遇到用户登录的需求，使用Django 用户认证（Auth）组件可以帮助我们判断当前的用户是否合法，快速实现用户登录、验证和退出。
Django中 LOGIN_URL 默认是 /accounts/login/ ，如果我们不设置就会跳转到 /accounts/login/ 页面去，因此需要我们覆写这个值，让它指向我们的登录页面。
使用django自带的装饰器 @login_required，就可以判断用户是否登录，只需要在相应的view方法的前面添加@login_required。
最后给大家做个展示：
你学会了吗，赶紧去试试吧！！！
三大器(装饰器,迭代器,生成器)
装饰器本质上就是一个闭包函数,他可以在不改变源码的情况下,增加其他的功能
应用场景:小范围的需要给类增加其他功能就可以使用装饰器
原则: 装饰器遵循开放封闭原则
函数的有效信息通常记录着一些有用信息,但是一旦和装饰器联系在一块的话,就会出现打印为空的现象
这是因为我们所执行的f() 函数实际上执行的是装饰器中的 inner() 函数,所以打印为空
但在django框架中使用的装饰器修复技术并不是这个
迭代 重复做一些事很多次（就现在循环中做的那样）
可迭代对象 Iterable 内部实现 __iter__ 方法 (可以直接作用于for循环的对象统称为可迭代对象,可以使用isinstance() 来判断 Iterable )
迭代器 Iterator 有 __next__ 方法的就是迭代器,迭代器是从第一个值开始一个一个的取,直到取完才结束, 中间只能前进不能后退,也不能生成值 可以通过 isinstance() 判断对象是否是 Iterator
生成器 具有 yeild 方法,生成器是基于迭代器的,不仅能取值,还能生成值.被执行后返回的是一个生成器 生成器的本质就是一个迭代器
通过列表生成式,我们可以直接创建一个列表.但是,受到内存限制,列表容量可定是有限的 .而且,我们创建一个包含100万个元素的列表,不仅占用很大的储存空间,如果我们仅仅需要访问前面几个元素,那后面绝大多数元素占用的空间都白白浪费了.
在Python中像列表生成器这样 一边循环一边计算的机制称为生成器 generator
要创建一个生成器 generator 有很多中方法
Python中迭代器的 本质上每次调用 next ()方法都返回下一个元素或抛出StopIteration的容器对象
由于Python中没有“迭代器”这个类，因此 具有以下两个特性的类都可以称为“迭代器”类 ：
1.有 __next__() 方法，返回容器的下一个元素或抛出StopIteration异常
2.有 __iter__() 方法，返回迭代器本身
虽然列表、字符串.....这些不是迭代器,但是我们可以把它变成迭代器
python装饰器有什么用
先来个形象比方
内裤可以用来遮羞，但是到了冬天它没法为我们防风御寒，聪明的人们发明了长裤，有了长裤后宝宝再也不冷了，装饰器就像我们这里说的长裤，在不影响内裤作用的前提下，给我们的身子提供了保暖的功效。
再回到我们的主题
装饰器本质上是一个Python函数，它可以让其他函数在不需要做任何代码变动的前提下增加额外功能，装饰器的返回值也是一个函数对象。它经常用于有切面需求的场景，比如：插入日志、性能测试、事务处理、缓存、权限校验等场景。装饰器是解决这类问题的绝佳设计，有了装饰器，我们就可以抽离出大量与函数功能本身无关的雷同代码并继续重用。概括的讲，装饰器的作用就是为已经存在的对象添加额外的功能。
先来看一个简单例子：
def foo():
print('i am foo')
现在有一个新的需求，希望可以记录下函数的执行日志，于是在代码中添加日志代码：
def foo():
print('i am foo')
logging.info("foo is running")
bar()、bar2()也有类似的需求，怎么做？再写一个logging在bar函数里？这样就造成大量雷同的代码，为了减少重复写代码，我们可以这样做，重新定义一个函数：专门处理日志 ，日志处理完之后再执行真正的业务代码
def use_logging(func):
logging.warn("%s is running" % func.__name__)
func()def bar():
print('i am bar')use_logging(bar)
逻辑上不难理解，
但是这样的话，我们每次都要将一个函数作为参数传递给use_logging函数。而且这种方式已经破坏了原有的代码逻辑结构，之前执行业务逻辑时，执行运行bar()，但是现在不得不改成use_logging(bar)。那么有没有更好的方式的呢？当然有，答案就是装饰器。
简单装饰器
def use_logging(func):
def wrapper(*args, **kwargs):
logging.warn("%s is running" % func.__name__)
return func(*args, **kwargs)
return wrapperdef bar():
print('i am bar')bar = use_logging(bar)bar()
函数use_logging就是装饰器，它把执行真正业务方法的func包裹在函数里面，看起来像bar被use_logging装饰了。在这个例子中，函数进入和退出时
，被称为一个横切面(Aspect)，这种编程方式被称为面向切面的编程(Aspect-Oriented Programming)。
@符号是装饰器的语法糖，在定义函数的时候使用，避免再一次赋值操作
def use_logging(func):
def wrapper(*args, **kwargs):
logging.warn("%s is running" % func.__name__)
return func(*args)
return wrapper@use_loggingdef foo():
print("i am foo")@use_loggingdef bar():
print("i am bar")bar()
如上所示，这样我们就可以省去bar =
use_logging(bar)这一句了，直接调用bar()即可得到想要的结果。如果我们有其他的类似函数，我们可以继续调用装饰器来修饰函数，而不用重复修改函数或者增加新的封装。这样，我们就提高了程序的可重复利用性，并增加了程序的可读性。
装饰器在Python使用如此方便都要归因于Python的函数能像普通的对象一样能作为参数传递给其他函数，可以被赋值给其他变量，可以作为返回值，可以被定义在另外一个函数内。
带参数的装饰器
装饰器还有更大的灵活性，例如带参数的装饰器：在上面的装饰器调用中，比如@use_logging，该装饰器唯一的参数就是执行业务的函数。装饰器的语法允许我们在调用时，提供其它参数，比如@decorator(a)。这样，就为装饰器的编写和使用提供了更大的灵活性。
def use_logging(level):
def decorator(func):
def wrapper(*args, **kwargs):
if level == "warn":
logging.warn("%s is running" % func.__name__)
return func(*args)
return wrapper
return decorator@use_logging(level="warn")def foo(name='foo'):
print("i am %s" % name)foo()
上面的use_logging是允许带参数的装饰器。它实际上是对原有装饰器的一个函数封装，并返回一个装饰器。我们可以将它理解为一个含有参数的闭包。当我
们使用@use_logging(level="warn")调用的时候，Python能够发现这一层的封装，并把参数传递到装饰器的环境中。
类装饰器
再来看看类装饰器，相比函数装饰器，类装饰器具有灵活度大、高内聚、封装性等优点。使用类装饰器还可以依靠类内部的\_\_call\_\_方法，当使用 @ 形式将装饰器附加到函数上时，就会调用此方法。
class Foo(object):
def __init__(self, func):
self._func = func
def __call__(self):
print ('class decorator runing')
self._func()
print ('class decorator ending')
@Foo
def bar():
print ('bar')
bar()
functools.wraps
使用装饰器极大地复用了代码，但是他有一个缺点就是原函数的元信息不见了，比如函数的docstring、__name__、参数列表，先看例子：
装饰器
def logged(func):
def with_logging(*args, **kwargs):
print func.__name__ + " was called"
return func(*args, **kwargs)
return with_logging
函数
@loggeddef f(x):
"""does some math"""
return x + x * x
该函数完成等价于：
def f(x):
"""does some math"""
return x + x * xf = logged(f)
不难发现，函数f被with_logging取代了，当然它的docstring，__name__就是变成了with_logging函数的信息了。
print f.__name__ # prints 'with_logging'print f.__doc__ # prints None
这个问题就比较严重的，好在我们有functools.wraps，wraps本身也是一个装饰器，它能把原函数的元信息拷贝到装饰器函数中，这使得装饰器函数也有和原函数一样的元信息了。
from functools import wrapsdef logged(func):
@wraps(func)
def with_logging(*args, **kwargs):
print func.__name__ + " was called"
return func(*args, **kwargs)
return with_logging@loggeddef f(x):
"""does some math"""
return x + x * xprint f.__name__ # prints 'f'print f.__doc__ # prints 'does some math'
内置装饰器
@staticmathod、@classmethod、@property
装饰器的顺序
@a@b@cdef f ():
等效于
f = a(b(c(f)))
python-复盘-装饰器应用场景大总结
装饰器能有助于检查某个人是否被授权去使用一个web应用的端点(endpoint)。它们被大量使用于Flask和Django web框架中。这里是一个例子来使用基于装饰器的授权：
日志是装饰器运用的另一个亮点。这是个例子：
我敢肯定你已经在思考装饰器的一个其他聪明用法了。
带参数的装饰器是典型的闭包函数 (略，参考我之前文章)
我们回到日志的例子，并创建一个包裹函数，能让我们指定一个用于输出的日志文件。
现在我们有了能用于正式环境的 logit 装饰器，但当我们的应用的某些部分还比较脆弱时，异常也许是需要更紧急关注的事情。比方说有时你只想打日志到一个文件。而有时你想把引起你注意的问题发送到一个email，同时也保留日志，留个记录。这是一个使用继承的场景，但目前为止我们只看到过用来构建装饰器的函数。
幸运的是，类也可以用来构建装饰器。那我们现在以一个类而不是一个函数的方式，来重新构建logit。
具体再参考我 之前文章 ，廖神讲解的更清晰
结语：以上就是首席CTO笔记为大家整理的关于django装饰器可以用来做什么的相关内容解答汇总了，希望对您有所帮助！如果解决了您的问题欢迎分享给更多关注此问题的朋友喔～