用了 tornado 也写网站，无它，当初就是因为喜欢，因为 tornado 的代码写得真心漂亮。
一开始我是这样组织项目的，你没有看错，真心只有这几个文件：
+ project
| - app.py （基本所有的 handler 都在这里了）
| - models.py （数据库相关的）
| + templates
| + static
如果要给个参考例子，那 BT 大大的项目来参考吧 https://github.com/finiteloop/socialcookbook 刚刚开始写 tornado 的项目的时候没有那么多的东西，一切都很简洁很美好！
然后呢，项目越来越多功能了，需要组织的代码越来越多，需要 Seesion ，需要 form 检验等一堆东西，于是重构为这样来组织项目：
+ project
| + controllers
| | - acontroller.py
| | - bcontroller.py
| | ....
| + models
| | - amodel.py
| | - bmodel.py
| | ....
| + templates
| + forms
| | - aform.py
| | - bform.py
| | ....
| + helpers
| | - ahelper.py
| | - bhelper.py
| | ....
| - application.py
| - urls.py
| - settings.py
很直接也很明显，这是拿 Tornado 来做 MVC 这龌龊的事情了，把先前越来越大的 app.py 分开成 controllers 目录， models 目录页一样，增加了 forms 目录和 helpers 目录。 application.py 放置整个 project 的启动、关闭， URL 放在 urls.py ， settings 嘛就是配置。
这样安好运行了好长一段时间，毕竟一个小网站，长成这样已经很对得起我拿的工资了。但是这样的项目结构随着业务的增多感觉越来越力不从心：
1 、首先业务关联比较多，类似于门户网站那样的 CMS 类型的，这样就无法分出几个项目来应用上面的代码组织了。
2 、子域名的需求众多，基本一个子域名 a.example.com 和 b.example.com 的代码逻辑是完全不一样的，但是数据库后面的数据却有很多需求重合的。同时原因见 1 ，又无法分出好几个 project 来组织代码
感觉越来越臃肿的代码结构，越来越多的东西加入到 Tornado 这个大杂烩里面，感觉项目长得越来越像 Django 的项目，但是组织却远不如 Django 的项目组织得好！
看了一下 Flask 的 Blueprint ，这货貌似在架构大型项目的时候很实用的样子。
就像这篇文章 https://spacewander.github.io/explore-flask-zh/7-blueprints.html 说到的按照功能(functional)或者分区(divisional)来组织代码。
按照 分区(divisional) 来组织代码貌似有天生的适合大型的且内部可以松耦合的项目，而类似我上面的 按照功能(functional) 来组织项目就适合组织功能相对内聚的项目。
按照我这么重构下去，迟早要弄个 Django 出来的感觉。有点后悔当初怎么不直接用 Django 而用上了 Tornado 来自己造各种轮子。
各位在架构 Tornado 的中大型项目，有什么经验可以分享吗？
谢谢！
一开始我是这样组织项目的，你没有看错，真心只有这几个文件：
+ project
| - app.py （基本所有的 handler 都在这里了）
| - models.py （数据库相关的）
| + templates
| + static
如果要给个参考例子，那 BT 大大的项目来参考吧 https://github.com/finiteloop/socialcookbook 刚刚开始写 tornado 的项目的时候没有那么多的东西，一切都很简洁很美好！
然后呢，项目越来越多功能了，需要组织的代码越来越多，需要 Seesion ，需要 form 检验等一堆东西，于是重构为这样来组织项目：
+ project
| + controllers
| | - acontroller.py
| | - bcontroller.py
| | ....
| + models
| | - amodel.py
| | - bmodel.py
| | ....
| + templates
| + forms
| | - aform.py
| | - bform.py
| | ....
| + helpers
| | - ahelper.py
| | - bhelper.py
| | ....
| - application.py
| - urls.py
| - settings.py
很直接也很明显，这是拿 Tornado 来做 MVC 这龌龊的事情了，把先前越来越大的 app.py 分开成 controllers 目录， models 目录页一样，增加了 forms 目录和 helpers 目录。 application.py 放置整个 project 的启动、关闭， URL 放在 urls.py ， settings 嘛就是配置。
这样安好运行了好长一段时间，毕竟一个小网站，长成这样已经很对得起我拿的工资了。但是这样的项目结构随着业务的增多感觉越来越力不从心：
1 、首先业务关联比较多，类似于门户网站那样的 CMS 类型的，这样就无法分出几个项目来应用上面的代码组织了。
2 、子域名的需求众多，基本一个子域名 a.example.com 和 b.example.com 的代码逻辑是完全不一样的，但是数据库后面的数据却有很多需求重合的。同时原因见 1 ，又无法分出好几个 project 来组织代码
感觉越来越臃肿的代码结构，越来越多的东西加入到 Tornado 这个大杂烩里面，感觉项目长得越来越像 Django 的项目，但是组织却远不如 Django 的项目组织得好！
看了一下 Flask 的 Blueprint ，这货貌似在架构大型项目的时候很实用的样子。
就像这篇文章 https://spacewander.github.io/explore-flask-zh/7-blueprints.html 说到的按照功能(functional)或者分区(divisional)来组织代码。
按照 分区(divisional) 来组织代码貌似有天生的适合大型的且内部可以松耦合的项目，而类似我上面的 按照功能(functional) 来组织项目就适合组织功能相对内聚的项目。
按照我这么重构下去，迟早要弄个 Django 出来的感觉。有点后悔当初怎么不直接用 Django 而用上了 Tornado 来自己造各种轮子。
各位在架构 Tornado 的中大型项目，有什么经验可以分享吗？
谢谢！
1
Select Language