zoukankan      html  css  js  c++  java
  • 浅谈Python Web的五大框架

    这里写图片描写叙述

    说到Web Framework,Ruby的世界Rails一统江湖,而Python则是一个百花齐放的世界。各种micro-framework、framework不可胜数.
    尽管还有一大脚本语言PHP也有不少框架,但远没有Python这么夸张,也正是由于Python Web Framework(Python Web开发框架,以下简称Python框架)太多。所以在Python社区总有关于Python框架孰优孰劣的话题,讨论的时间跨度甚至长达3-5年。


    Python这么多框架,能挨个玩个遍的人不多,坦白的说我也仅仅用过当中的三个开发过项目,另外一些略微接触过,所以这里仅仅能浅谈一下,欢迎懂行的朋友们补充。

    Django
    这里写图片描写叙述

    Python框架尽管说是百花齐放。但仍然有那么一家是最大的,它就是Django。

    要说Django是Python框架里最好的。有人允许也有人 坚决反对。但说Django的文档最完好、市场占有率最高、招聘职位最多预计大家都没什么意见。Django为人所称道的地方主要有:

    · 完美的文档,Django的成功。我认为非常大一部分原因要归功于Django近乎完美的官方文档(包含Django book)。
    · 全套的解决方式,Django象Rails一样,提供全套的解决方式(full-stack framework + batteries included)。基本要什么有什么(比方:cache、session、feed、orm、geo、auth)。并且所有Django自己造。开发网 站应手的工具Django基本都给你做好了。因此开发效率是不用说的,出了问题也算好找。不在你的代码里就在Django的源代码里。


    · 强大的URL路由配置。Django让你能够设计出非常优雅的URL。在Django里你基本能够跟丑陋的GET參数说拜拜。
    · 自助管理后台。admin interface是Django里比較吸引眼球的一项contrib,让你差点儿不用写一行代码就拥有一个完整的后台管理界面。


    而Django的缺点主要源自Django坚持自己造所有的轮子,整个系统相对封闭,Django最为人诟病的地方有:
    · 系统紧耦合,假设你认为Django内置的某项功能不是非常好。想用喜欢的第三方库来取代是非常难的。比方以下将要说的ORM、Template。要在Django里用SQLAlchemy或Mako差点儿是不可能,即使打了一些补丁用上了也会让你认为非常非常别扭。
    · Django自带的ORM远不如SQLAlchemy强大。除了在Django这一亩三分地,SQLAlchemy是Python世界里事实上的ORM标准,其他框架都支持SQLAlchemy了。只有Django仍然坚持自己的那一套。Django的开发者对SQLAlchemy的支持也是有 过讨论和尝试的,只是终于还是放弃了,预计是代价太高且跟Django其他的模块非常难合到一块。
    · Template功能比較弱,不能插入Python代码,要写复杂一点的逻辑须要另外用Python实现Tag或Filter。
    · URL配置尽管强大,但所有要手写,这一点跟Rails的Convention over configuration的理念全然相左,高手和初识Django的人配出来的URL会有非常大差异。


    · 让人纠结的auth模块,Django的auth跟其他模块结合紧密。功能也挺强的。就是做的有点过了,用户的数据库schema都给你定好了。这样问题就来了,比方非常多站点要求email地址唯一,可schema里这个字段的值不是唯一的。纠结是必须的了。
    · Python文件做配置文件,而不是更常见的ini、xml或yaml等形式。这本身不是什么问题,但是由于理论上来说settings的值是能够动态的改变的(尽管大家不会这么干),但这不是最佳实践的体现。


    总的来说。Django大包大揽。用它来高速开发一些Web运用是非常不错的。

    假设你顺着Django的设计哲学来,你会认为Django非常好用。越用越顺手;相反,你假设不能融入或接受Django的设计哲学,你用Django一定会非常痛苦,趁早放弃的好。所以说在有些人眼里Django无异于仙丹, 但对有一些人来说它又是毒药且剧毒。
    Pylons & TurboGears & repoze.bfg

    这里写图片描写叙述

    除了Django还有一个大头就是Pylons了。由于TurboGears2.x是基于Pylons来做的。而repoze.bfg也已经并入Pylons project里这个大的项目里,后面不再单独讨论TurboGears和repoze.bfg了。

    Pylons和Django的设计理念全然不同,Pylons本身仅仅有两千行左右的Python代码,只是它还附带有一些差点儿就是Pylons御用 的第三方模块。Pylons仅仅提供一个架子和可选方案。你能够依据自己的喜好自由的选择Template、ORM、form、auth等组件。系统高度可 定制。我们常说Python是一个胶水语言(glue language)。那么我们全然能够说Pylons就是一个用胶水语言设计的胶水框架。
    选择Pylons多是选择了它的自由,选择了自由的同一时候也预示着你选择了噩梦:
    · 学习噩梦。Pylons依赖于很多第三方库,它们并非Pylons造,你学Pylons的同一时候还得学这些库怎么使用,关键有些时候你都不知道你 要学什么。

    Pylons的学习曲线相对照Django要高的多。而之前Pylons的官方文档也一直是人批评的对象。好在后来出了The Definitive Guide to Pylons这本书,这一局面有所改观。由于这个原因。Pylons一度被誉为仅仅适合高手使用的Python框架。
    · 调试噩梦,由于牵涉到的模块多,一旦有发生错误就比較难定位问题处在哪里。可能是你写的程序的错、也可能是Pylons出错了、再或是SQLAlchemy出错了、搞不好是formencode有bug,反正非常凌乱了。这个仅仅实用的非常熟了才干解决问题。
    · 升级噩梦,安装Pylons大大小小共要安装近20个Python模块,各有各自的版本号号,要升级Pylons的版本号,哪个模块出了不兼容的问题都有可能,升级基本上非常难非常难。

    至今reddit的Pylons还停留在古董的0.9.6上,SQLAlchemy也还是0.5.3的版本号,应该跟这条有关系。
    Pylons和repoze.bfg的融合可能会催生下一个能挑战Django地位的框架。

    Tornado & web.py
    这里写图片描写叙述

    Tornado即是一个Web server(对此本文不作详述)。同一时候又是一个类web.py的micro-framework。作为框架Tornado的思想主要来源于Web.py,大家在Web.py的站点首页也能够看到Tornado的大佬Bret Taylor的这么一段话(他这里说的FriendFeed用的框架跟Tornado能够看作是一个东西):
    “[web.py inspired the] Web framework we use at FriendFeed [and] the webapp framework that ships with App Engine…”
    由于有这层关系,后面不再单独讨论Tornado。
    Web.py的设计理念力求精简(Keep it simple and powerful),总共就没多少行代码,也不像Pylons那样依赖大量的第三方模块,而是仅仅提供的一个框架所必须的一些东西,如:URL路由、 Template、数据库訪问,其他的就交给用户自己去做好了。


    一个框架精简的优点在于你能够聚焦在业务逻辑上,而不用太多的去关心框架本身或受框架的干扰,同一时候缺点也非常明显,很多事情你得自己操刀上。
    我个人比較偏好这样的精简的框架。由于你非常easy通过阅读源代码弄明确整个框架的工作机制,假设框架那一块不是非常合意的话。我全然能够Monkey patch一下按自己的要求来。

    Bottle & Flask
    这里写图片描写叙述

    Bottle和Flask作为新生一代Python框架的代表。挺有意思的是都採用了decorator的方式配置URL路由,如:

    from bottle import route, run
    @route(‘/:name’)
    def index(name=’World’):
    return ‘<b>Hello %s!</b>’ % name
    run(host=’localhost’, port=8080)
    Bottle、Flask跟web.py一样。都非常精简,Bottle甚至所有的代码都在那一个两千来行的.py文件中。另外Flask和Pylons一样,能够跟Jinja2、SQLAlchemy之类结合的非常好。


    只是眼下无论是Bottle还是Flask成功案例都还非常少。
    Quixote
    之所以要特别说一下Quixote,是由于国内的最大的用Python开发的站点“豆瓣网”是用Quixote开发的。

    我仅仅简单翻了一下源代码。没有做过研究,不发表评论,有经验的来补充下。

    我仅仅是在想,假设豆瓣网交到如今来开发。应该会有很多其他的选择。
    其他(web2py、uliweb、Karrigell、Werkzeug …)

    最后关于框架选择的误区
    在框架的选择问题上,很多人非常easy就陷入了以下两个误区中而不自知:

    1. 哪个框架最好——世上没有最好的框架,仅仅有最适合你自己、最适合你的团队的框架。

    编程语言选择也是一个道理,你的团队Python最熟就用Python好了。假设最熟悉的是Ruby那就用Ruby好了,编程语言、框架都仅仅是工具,能多、快、好、省的干完活就是好东西。

    2. 过分关注性能——事实上大部分人是不是必需太关心框架的性能的。由于你开发的站点根本就是个小站,能上1万的IP的站点已经不多了,上10万的更是非常少非常少。

    在没有一定的訪问量前谈性能事实上是没有多大意义的,由于你的CPU和内存一直就闲着呢。

    并且语言和框架一般也不会是性能瓶颈,性能问题最常出如今数据库訪问和文件读写上。 PHP的Zend Framework是出了名的慢,但是Zend Framework一样有大站,如:digg.com;常被人说有性能问题的Ruby和Rails,不是照样能够开发出twitter吗?再者如今的硬 件、带宽成本事实上是非常低的,特别有了云计算平台后,人力成本才是最贵的,没有上万的IP根本就不用太在意性能问题,流量上去了花点钱买点服务器空间好了。 简单高速的解决性能问题。

  • 相关阅读:
    Mysql高手系列
    Mysql高手系列
    Mysql高手系列
    Mysql高手系列
    Mysql高手系列
    Mysql高手系列
    Mysql高手系列
    Mysql高手系列
    Mysql高手系列
    Mysql高手系列
  • 原文地址:https://www.cnblogs.com/cynchanpin/p/7026771.html
Copyright © 2011-2022 走看看