一、一般程序的实现过程：

• 以前写Flask程序时，一般只有一个app.py主程序来实现后台逻辑
  
• 如果需要模板，会在程序中创建一个templates文件夹；
  
• 但是，当程序逐渐复杂时，将全部函数放在一个py文件内时，就显得过于凌乱，不符合python的优雅风格；
  
• 所以，我们希望把实现不同业务逻辑的view_func视图函数分别放在不同的py文件中。
• 例如，创建一个文件夹，名为view;内部创建的py文件为：account.py、user.py、order.py 分别代表账户相关，用户信息相关，订单相关；
  
• 但是，每一个业务逻辑的py文件都有一个共同的app应用，所以需要在view文件夹内部创建一个__init__.py，其作用是实例化app即app=Flask(__name__)
  
• 然后，在每个业务逻辑文件中，导入app；
  
• 由于app.py中的业务逻辑已经被其他文件分摊，所以，app.py 就可以只负责启动程序环节，另外，在根目录导入文件时，不能直接用.，而是要用 from 文件夹 import 文件名或者__init__下的函数名；
• 但在运行起来之后，会发现运行错误，原因是：在__init__文件中实例化app,然后再app.py中导入app并执行，其中其他的业务逻辑文件并没有关联执行；
  
• 所以，要在__init__文件中，要让业务逻辑文件关联app，这样运行顺序就会是：1.__init__中创建app；2.导入其中一个业务逻辑文件，业务逻辑文件同时也导入了app文件，注册路由并实现业务逻辑代码。
  

二、使用蓝图的好处

• 在上面一般程序实现中，存在相互导入的过程，具有较强的关联性，这不利于开发和管理程序；
• 在蓝图中，通过__init__文件的蓝图导入步骤，可以帮助业务逻辑文件实现相对独立的开发管理环境

三、蓝图的定义（Blueprint）

• 蓝图是一个对象，它允许定义应用程序功能而无需提前使用应用程序对象。它的使用与：class：〜flask.Flask修饰符类似，但通过记录它，可以在以后注册时，满足应用程序的需求。

四、如果使用蓝图

• 在使用蓝图之前，仍在将各种业务逻辑文件进行分类归纳
  
  • 其中，__init__里面创建app，并导入两种内容：1.业务逻辑对象（即业务逻辑函数名）；2.创建后的蓝图名；
    
  • 而在每个业务逻辑文件中，都要创建蓝图，并以蓝图名注册路由；如：

五、蓝图参数：

1. name:蓝图的名称。将在每个端点名称之前。

2. import_name：蓝图包的名称，通常为__name__。这有助于找到蓝图的 root_path。

3. static_folder：具有静态文件的文件夹。该文件应由蓝图的静态路由提供。该路径相对于蓝图的根路径。蓝图静态文件默认为禁用。

4. static_url_path：用于提供静态文件的网址。默认为``static_folder’’。如果该蓝图没有url_prefix，则该应用程序的静态路由将优先，并且该蓝图的静态文件将不可访问。

5. template_folder：设置蓝图自定义模板路径，蓝图模板默认为禁用。蓝图模板的优先级低于应用程序模板文件夹中的优先级（也就是和说，如果创建flask的时候，要先删掉应用程序自带模板，才能使用蓝图自定义模板）。
   

6. url_prefix：统一给某一类蓝图的URL加前缀。
   

   在输入地址时，必须在路由前面加一个自定义的前缀；
   

7. subdomain：默认情况下，蓝图路由的子域将匹配。

8. url_defaults：蓝图路由将默认接收的默认值的字典。

9. root_path：默认情况下，蓝图将基于``import_name’'自动执行此操作。在某些情况下，此自动检测可能会失败，因此可以手动指定路径。

六、执行优先级

• 执行程序时，如果在根目录下设置一个初始化函数，并在其中定义app；系统会默认优先执行__init__.py内的内容。
• 如果在业务逻辑文件中创建请求扩展，依然会被执行，但会在初始化文件执行之后；

七、一个程序写多个app的结构（大型应用程序）

• 依然是先创建Flask框架，并导入业务逻辑文件；
• 在每个业务逻辑文件夹中创建一个完整的flask简单框架
  
• 在框架内，每个__init__文件也可以创建一个蓝图
•