Flask视图：视图函数，类视图，蓝图使用方法整理

摘要： Flask ， 视图 ， 视图函数 ， 类视图 ， 方法视图 ， 装饰器 ， 蓝图

在Flask中 路由 是指用户请求的 URL 与 视图函数 之间的 映射 ，处理URL和函数之间关系的程序称为路由。Flask根据HTTP请求的URL在路由表中匹配预定义的URL找到对应的视图函数。将视图函数的执行结果返回给服务器。

Flask中默认使用 @app.route 装饰器将视图函数和URL绑定，装饰器是一种接受函数的函数，返回新的函数。

使用装饰器将视图函数page和url '/'关系绑定带 app.url_map 属性上，打印app.url_map的结果如下，有两条url规则，分别是根目录下的URL规则和static目录下的URL规则

可以给装饰器增加 endpoint 参数给 url命名 ，一旦使用了endpoint参数 url_for 反转就不能使用视图函数名了而要使用定义的url名。

url_for('index')的输出是字符串格式url的内容"/"

也可以不使用装饰器，使用 add_url_rule 将视图函数和url绑定，装饰器 @app.route 实际是调用的 add_url_rule 方法

视图函数也可以结合类来实现，类视图的好处是支持 继承 ，可以将共性的东西放到父类中，类视图需要使用 app.add_url_rule() 来进行注册，类视图分为 标准类视图 和 基于调度方法的类视图

标准类视图有标准的写法

使用类视图，在父类中定义一个属性，在子类中完成各自的业务逻辑，同时都继承父类中的这一个属性

分别定义三个子类的模板

查看结果，三个url的返回除了三个模板各自的内容外都需要输出父类的ads属性

如果同一个视图函数需要根据 不同的请求方式 进行不一样的逻辑处理，需要在视图函数内部进行判断，可以使用 方法类视图 实现，使用类继承 flask.views.MethodView ，定义和请求方式 同名的小写方法 来完成了逻辑处理。

编辑一个页面直接访问是输出用户名密码页面，提交表单后是密码正确与否的提示。

在html中定义 form 标签action属性关联url名

如果不用方法视图实现需要在普通视图内部调用 request.method 判断是否为 GET ， POST 进行判断

装饰器的本质是一个Python函数， 接受一个函数 ， 返回一个函数 ，目的是让一个函数获得 其他额外的功能 。

假设一个场景访问新闻详情页又一个函数实现，但是之前必须先登录，登录由另一个函数实现，此时需要将访问新闻函数传递给登录函数返回一个新的函数作为整体的逻辑实现，这个给登录函数增加新功能浏览网页的过程就是装饰器。

控制台输出，new_func()执行了新函数，基础函数user_login执行了新加入的功能，新函数真实的函数名还是inner

如果使用装饰器魔法符号实现，此时直接调用被装饰的函数即可实现带有新功能的基础函数，函数作为参数传入的过程已经自动实现

在基础函数和要包装的函数上都支持传递参数

查看 app.route() 的源码内部也是将视图函数包装，在原函数执行之前调用 add_url_rule 绑定url，endpoint和视图函数的关系，再返回原函数实现业务逻辑

蓝图的目的是实现 各个模块的视图函数写在不同的py文件中 ，在主视图中导入分路由视图的模块，并注册蓝图对象， 降低各个功能模块的耦合度 ，使用 flask.Blueprint 定义蓝图， app.register_blueprint 注册蓝图。

实现主页，详情页，对比页三个页面，在主页中导入两个其他功能页，先编写两个功能页的蓝图detail.py和compare.py

使用 app = Blueprint('detail', __name__) 定义蓝图对象， detail 是蓝图名，蓝图名不能重复。再编写主视图main.py，在主视图中注册之前的蓝图，其他视图函数的名字不能和蓝图名一致

查看效果

如果在蓝图的py脚本中调用了 url_for ，需要把蓝图的name（就是 name 之前的）也加入作为前缀，如下

SQL Server系统视图之复制视图

这些视图包含 Microsoft SQL Server 中由复制使用的信息。 使用这些视图可以更轻松地访问复制系统表中的数据。将某个用户数据库启用为发布数据库或订阅数据库时，便会在该数据库中创建视图。 从复制拓扑中删除用户数据库时，便会删除该数据库中的所有复制对象。 访问复制元数据的首选方法是使用复制存储过程。

任何用户都不应直接更改系统视图。

动态管理视图和函数

动态管理视图和函数返回可用于监视服务器实例的运行状况、诊断故障以及优化性能的服务器状态信息。

动态管理视图和函数返回特定于实现的内部状态数据。在未来的 SQL Server 版本中，它们的架构和返回的数据可能会发生更改。因此，未来版本中的动态管理视图和函数可能与 SQL Server 2008 中的动态管理视图和函数不兼容

动态管理视图和函数分为两种类型：

服务器范围内的动态管理视图和函数。此类型需要具有该服务器的 VIEW SERVER STATE 权限。

数据库范围内的动态管理视图和函数。此类型需要具有该数据库的 VIEW DATABASE STATE 权限。

SQL Server系统视图之查询动态管理视图

通过使用两部分、三部分或四部分所组成的名称，可在 Transact-SQL 语句中引用动态管理视图。另一方面，也可使用两部分或三部分所组成的名称在 Transact-SQL 语句中引用动态管理函数。不能使用只由一部分组成的名称在 Transact-SQL 语句中引用动态管理视图和函数。

所有动态管理视图和函数都存在于 sys 架构中，并遵循 dm_* 命名约定。当使用动态管理视图或函数时，必须使用 sys 架构作为视图或函数名称的前缀。例如，若要查询 dm_os_wait_stats 动态管理视图，请运行以下查询：

SELECT wait_type, wait_time_ms FROM sys.dm_os_wait_statsGO

所需的权限

查询动态管理视图或函数需要对于对象具有 SELECT 权限以及 VIEW SERVER STATE 或 VIEW DATABASE STATE 权限。这样您可以有选择地限制用户或登录名对动态管理视图和函数的访问。为此，首先在 master 中创建用户，然后拒绝该用户对不希望被访问的动态管理视图或函数的 SELECT 权限。此后，无论该用户的数据库上下文如何，用户都将无法选择这些动态管理视图或函数。

这章是跟着上一章讲的，如有不适应请点击 上一章

服务器里的路由是一个非常重要的角色，它控制了路径与视图函数的关联。

url的是统一资源定位符，对可以从 互联网 上得到的资源的位置和访问方法的一种简洁的表示，是互联网上标准资源的地址。互联网上的每个文件都有一个唯一的URL，它包含的信息指出文件的位置以及浏览器应该怎么处理它。

常见的url是：122.227.20.190:8000/index

可以分成：

通俗的讲

Werkzeug 库的routing模块的主要功能在于URL解析。对于WSGI应用来讲，不同的URL对应不同的视图函数，routing模块则会对请求信息的URL进行解析并匹配，触发URL对应的视图函数，以此生成一个响应信息。routing模块的解析和匹配功能主要体现在三个类上：Rule、Map和MapAdapter。

Rule类继承自RuleFactory类。一个Rule的实例代表一个URL模式，一个WSGI应用可以处理很多不同的URL模式，这也就是说可以产生很多不同的Rule实例。这些Rule实例最终会作为参数传递给Map类，形成一个包含所有URL模式的对象，通过这个对象可以解析并匹配请求对应的视图函数。

关于Rule类有一些常用的方法：

rule实例化时至少接受一个参数，其他的都是默认参数。这个类实现了match,build等方法。主要的方法有get_url方法，这个方法重写了父类RuleFactory的方法，返回的是自身的生成器。这个方法与submain等其他的类的实现方法不同，在submain类中，这个类本身包含了rule类，故调用get_urls方法首先获得rule实例，再一次调用get_url得到一个生成器。

另外一个方法是bind方法，这个方法将rule实例绑定到map实例上,绑定后的rule能够使用map属性的方法。

通过Map类构造的实例可以存储所有的URL规则，这些规则是Rule类的实例。Map实例可以 通过后续的调用和给定的URL进行匹配。

关于Map类有一些常用的方法：

map类相当于一个存放Rule类的容器，实现的方法能对rule进行操作，也是url进入特定视图函数的中介。

MapAdapter主要是获取请求的url参数，将参数传递至相关视图函数中，进行处理。

---