选择Web开发框架时需要考虑的15个重要因素

    新的Web开发框架正在以一种人们无法企及的速度涌现出来。在本文中，我们将会讨论你的下一个热门Web应用程序应该使用什么样的框架。
    在如今这个时代，抢在您的竞争对手之前发布一个已完成的优雅的应用程序是至关重要的。从头开始编写代码(琐碎事情除外)是一件很费时的事，开发者要花很多时间去重新发明轮子，而这些时间如果用于开发新功能或完善代码会更好。
    这就是Web开发框架存在的理由。它们往往已经包含了应用程序中所有的通用模块，包括数据库存取、权限控制、会话管理以及其它更多功能。
    今天，我们将会讨论的是，你在选择一个框架之前所需要关心的各方面因素。有兴趣吗？那就马上开始。

1. 使用环境

    在你开始考察一个框架之前，你需要列出你的需求，看看这框架能否满足它们。
    如果符合下面这些情形，你需要使用框架：
        你的应用程序主要基于CRUD操作；
        你需要将UI与底层逻辑合理地分开，但你没有时间去实现一个合适的系统；
        你发现你为自己的Web应用程序所编写的程序库覆盖了用户授权、会话以及其它相关的常用功能；
        你的老板希望你能在两天内为他开发一个CMS，而且你已经对框架有所了解；

如果符合下面这些情形，你就不需要框架：
    你需要一个单独的漂亮的URL系统；
    你只需要框架的某一特定部分，如ORM；
    你的时间很紧，而且你必须从头开始学习框架；
    有人告诉你框架能治疗癌症；

2. 许可证

    在你开始使用框架进行开发之前，你得看一下这个框架是基于什么许可证发布的。尽管大部分许可证对于商业应用开发来说是自由的，但仍有一部分不那么自由。你最不希望看到的情况就是，你做完了整个应用程序后才发现，框架的许可证不允许你以商业形式发布代码。事先做好研究功课总好过事后的痛苦。
    切记这不仅仅限制框架本身。你用于额外功能的插件或者扩展项都可能有一个隐藏的使用条款，所以你还得检查一下它的许可证才行。

3. 软件模式

    几乎所有的框架都无一例外地使用了MVC模式。MVC代表的是Model(模型)-View(视图)-Controller(控制器)，帮助你保存数据：模型，业务逻辑——控制器以及用户界面——视图，都是各自分开的。这些允许你编写更好更完善的代码，最终完成更好的应用程序。大家都用MVC并不代表你只需要知道这么多。还有其他不同的变种，包括MVP:Model(模型)-View(视图)-Presenter(呈现器), MVA: Model(模型)-View(视图)-Adapter(适配器) 以及 AVC: Application(应用程序)-View(视图)-Controller(控制器)。

4. 主机需求

    作为Web开发者，我们可能更倾向于使用最尖端最顶级的平台，但是我们往往先要考虑到客户的需求以及预算的限制。使用独享主机来发布我们的应用程序往往会导致超出预算，因此我们不得不使用那些拥有正常模块和配置的共享主机。
能很好兼容共享主机的框架包括：
CodeIgniter
CakePHP
Kohana
Zend Framework
大多数其它 PHP框架

安装起来相对复杂的框架包括：

Ruby on Rails
Django
Pylons
大多数非PHP框架

    事实上，你还是能够在共享主机上运行类似于Django的框架，前提是服务器上已经安装了必需的模块。你也可以在CGI模式下运行它，但速度会比原生模式慢很多。

5. 安装容易程度

    选择框架时，安装容易程度也是很重要的因素。一个框架，无论是重量级还是轻量级，如果使用者需要经过一系列繁琐步骤才能安装并且运行它，这就是问题了。
    当应用程序已准备就绪并且测试完成，需要发布到生产服务器上的时候，这也会导致一个大问题。在这种情况下，一个安装和部署都很简单的框架就很有意义。
    对大多数框架而言，安装过程和设置配置文件中的正确参数一样简单，然而对其它框架来说就是一件费时费力的事情。选择一个能让你尽快上手运行的框架。

6. 学习曲线

    每个框架都有它自己的小宇宙：命名规范、目录结构以及诸如此类的东西。某些框架在这方面非常灵活，而其它的就非常严格，例如在出现极小的错误时要抛出错误都非常繁琐。
    某些框架在实现一个功能的时候会遵循一个规范，而其它的就各行其是。
    在选择框架的时候，记住要选择学习曲线最平缓的那个。如果你不知道这框架是用什么语言编写的，那就必须把学习这语言本身的学习曲线也考虑在内。我曾见过不少从CakePHP转向Django的开发者，他们不得不同时学习Python和Django，因此他们纷纷表示压力很大。
    如果你需要同时学习框架和它所使用的语言，你就得悠着点了。

7. 代码库

让我们面对这样一个现实，那就是，人们接受一个框架是因为它的核心库。库必须能让你从编写重复代码的过程中解脱出来，同时也能允许你自行增加更多的功能和特性。
大多数框架提供了以下大部分功能的类库：
AJAX
身份验证
授权
缓存
数据清理
数据验证
模板
URL 映射和重写

    当然，并不是人人都需要一个包罗万象的框架。很多人更希望框架能处理小部分功能而让开发者来处理剩下的那部分。在这些情况下，你需要确保你所考虑的框架是否只拥有你所需要的特性。
    目前框架中流行的趋势是以类库的形式创建框架。换句话说，它允许你根据需要来对库进行替换。在这方面的绝佳典范就是Pylons。它甚至允许你替换它的大多数部分，从ORM到模板语言都行。相对于那些紧耦合的框架，人们喜欢这种松耦合的框架。

8. 数据库抽象以及ORM

    几乎所有应用程序都要存取数据库。如论如何，你都要在开发整个应用程序的过程中这么做，大多数框架都提供了数据库存取类给你使用。因此，当你在选择应用程序的时候，选择能使你的应用程序变得与数据库无关的那一个。万一你要切换数据库，而如果你的框架为你做了这些工作的话，你永远都不用在数据库那部分操心。
    你所要考虑的第二部分就是框架的ORM功能。不需太多技巧，ORM或者Object Relational Mapping(对象关系映射)允许你将数据以对象的形式表现出来，并且将它与其它对象关联起来。如果你想的话，想象一下一个能够获取信息的对象数据库。
包含了ORM特性的框架包括：CakePHP、Django以及Ruby。使用类似Pylons的框架的时候你甚至可以用你自己选择的ORM。

9. 内置的JS库

    争论的另一点就是捆绑的JavaScript库。大多数允许你轻松地切换，然而框架内置的AJAX方法大多数情况下仍然只针对某一特定的JS库。这种潜规则意味着你将不得不手动去开发那一功能。
    另一方面，提供了通用方法的那些框架对你来说的好处是，你可以轻而易举地切换你要使用的JavaScript库。
仅供参考：CakePHP和Ruby on Rails能够以标准形式在Prototype和Scriptaculous之间切换。

10. 单元测试

    我就是那种极其依赖于单元测试的开发者。维基百科上对单元测试的定义是这样的：
单元测试是一种软件检验测试方法，程序员可以通过它来测试源代码中的单个部分是否符合要求。一个单元就是应用程序中最小的可测试的部分。
    在这种情况下，能让我编写单元测试的框架对我很有益处。很多框架，如CodeIgniter、CakePHP还有Zend都允许你创建自定义的测试，作为对核心测试的补充，目的是对应用程序的重要部分进行检查。

11. 可伸缩性

    一般的Web开发者不必考虑框架的可伸缩性问题。通常情况下I/O和网络延迟比框架的可伸缩性更为重要。甚至Twitter那神话般的可伸缩性问题都不是所考虑的框架本身的过错。如果有人要求你放弃一个框架并指出它的伸缩问题，你可以笑而不语。伸缩问题的原因很少由框架产生。当然你也可以对代码稍作优化，但是通常情况下伸缩问题的主要原因在别的方面。

12. 文档

    框架的文档往往是它能否成功的关键。解释详尽的文档能够吸引更多用户和爱好者。质量差的、令人费解的文档会使人们感到迷惑并且惹恼他们，使他们放弃该框架。
    寻找一个文档中包含有丰富的范例、实例代码、文章以及教程的框架。

13. 社区

    尽管有合适的文档，但你不可避免地还是会遇到需要解决的问题，因此你需要去框架的支持社区寻求帮助。我个人已经在很多个社区进行过交流，其中一个社区的成员尖酸刻薄地对新手进行嘲笑，然而另一个社区的成员们却十分热心地为新手提供力所能及的帮助。因此对于最终选择的是哪个框架开始工作的这一问题，我就不做解释了。
    如果一直如此，支持社区将会成就或者毁掉一个框架。社区成员表现得这样急功近利的话，你将会对框架心生怨恨，而不是那些人。社区成员表现得彬彬有礼的话，你就会更倾向于选择那个框架。如果框架拥有友好的社区，能够为新开发者提供帮助的话，那就选择它。

14. Bug 修复/更新

    Web开发者们不愿意自己编写框架的原因之一是他们将要独自完成bug的修复以及更新工作。而对于一个大的框架，每天都有成千上万的开发者对代码进行审视。一旦发现有bug，就能立即得到修复。
    选择一个不那么死气沉沉的框架。你不希望有黑客来告诉你框架有个安全漏洞可以被用来入侵你的网站吧。相对而言，你更希望由框架的开发者们给你提供一个补丁来修正问题。 选择一个更新频繁的框架，更重要的是该框架是开放性的，大家都能发现bugs和尽快修复它们。

15. 创建扩展的容易程度以及可用性

    尽管框架覆盖了一个应用程序的重要基础部分，但是你还需要编写一些代码。尽量使它变得通用，这样你就可以在你的其它应用程序中对它进行重用，甚至是公开发布给人们使用。
    选择一个能够让你轻松进行扩展的框架。以CakePHP为例，扩展一个控制器需要顾及到各个组件以及由辅助函数和视图。无论是那种情况，创建一个扩展就像定义一个继承于父类的子类一样简单。
    选择框架的时候，记住要考虑到插件的可用性。通常情况下你没有时间从头开始创建一个自定义扩展。拥有一个巨大的扩展库可供选择，这就在很大程度上解决了这一问题。扩展的质量比数量更重要。

结论

    现在我们已经讨论了你在选择框架之前所应该考虑的各个方面，包含从框架是否满足需要到bug修复和更新在内的所有内容。但愿这对你有所帮助，也希望你能觉得有趣。