不使用框架的参数

这意味着框架是由一些未知的英雄编写的,他们在默认情况下比你聪明。
但如果事实并非如此。
它有缺陷,可能是混乱的,不必要的过度复杂。 因此,拥有自己的助手库通常比使用这样一个怪物更方便,因为它知道大约10%的特性。

一些想法:

1. 您正在创建的类型应用程序没有可用的商业或免费框架(考虑到自定义的基于硬件的应用程序)(这是显而易见的答案)
2. 系统的可扩展性需求通过使用RAD框架而变得更加困难(即,框架值约定超过配置,在这里您真正需要配置)
3. 项目范围足够小,以至于使用RAD框架投资学习曲线是没有意义的(如果您已经超过了学习曲线,这可能适用,也可能不适用)
4. 框架提供的工具/方法/后端/平台要求将带来不必要的复杂性(Yagni,使用不需要业务需求的框架,其功能可能会增加支持成本,因为您必须支持整个框架,包括未使用的功能)

我一直担心,当一个框架停止维护/更新(无论什么原因)时会发生什么?您的项目被锁定在框架支持的任何php/mysql版本中。

我最近在做一些框架研究。
http://matrix.include-once.org/framework/

在某种程度上,我不得不同意。大多数框架并没有显著地简化开发。特别是“MVC”框架更多的是抽象而不是实用性。但是,总是有一些功能可以帮助完成日常任务。ActiveRecord/ORM让人想起减少了繁琐的手工工作。表单帮助者可能会这样做,但我还没有看到一个真正有用的表单帮助者。

我相信,框架提供的功能库代码越多,工作效率就越高。但在Zend框架的情况下,它的复杂性使其随机性相形见绌。但是,检查一些较小的框架。避免过于抽象。查找脚手架工具,而不是库。

不使用框架的一个主要优点是,您可以在代码方面具有更大的灵活性。对于规模较小的项目,拥有这种灵活性通常更好。

• 一些框架需要shell访问来部署。
• 可伸缩性,我已经读到切分是一个问题
• 如果性能是优先考虑的,那么框架会降低执行速度
• 不是所有熟悉MVC模式的开发人员都熟悉,所以,如果开发人员在项目中/项目外轮换,那么维护性可能是一个挑战。