不使用框架的参数

Question

不久前我阅读了一篇很好的文章，其中介绍了使用任何适用于PHP的RAD框架的许多原因。基本上，它认为一个好的框架应该让你快速离开地面，然后应该摆脱困境。但是没有一个PHP框架能够做到这一点。它指出，Django擅长这样做（但显然这不是PHP框架）。

对于我的生活，我现在找不到这篇文章。

所以我很好奇。有没有人有任何坚实的论点，为什么不应该建立在RAD框架之上的应用程序？而且我不一定在谈论泛型应用（定义框架试图解决一个通用的问题，问题在于它能很好地解决特定的问题）。

当我说建立在顶端时，我的意思是从底层开始基于框架。我并不是指将框架称为一系列图书馆。我的意思是将应用程序的整个架构置于框架之外（然后将您绑定到框架中）。

我也没有真正谈论快速原型，代码可能会被重写。我更关注具有特定业务需求的长期应用程序，并且必须在相当长的时间内得到支持和维护（和修改）。

我们总是听到为什么我们应该使用框架。我们有理由嘉豪：

• 不重新发明轮子（虽然我很讨厌这个原因）
• 更快的开发时间（因为架构是跳过）
• 更容易在
• 常见问题带来新的开发者已经解决
• 等...

但是我正在寻找的对立面......

有什么想法？

Answer 1

这意味着某些未知英雄所写的框架默认比你聪明。
但事实上，事实往往并非如此。
它有错误，它可以是混乱和不必要的过分复杂。因此，拥有自己的助手库通常比使用这种怪物更方便，大概知道它的10％的特征。

Answer 2

几个想法：

1. 要创建没有可用的商用或免费的框架（定制的基于硬件的应用浮现在脑海中）应用类型（这是显而易见的答案）
2. 的系统具有可扩展性要求，通过使用RAD框架使框架变得更加困难（即，框架值约定优于配置，您确实需要配置）
3. 项目范围足够小，因此投资学习曲线没有意义变成使用RAD框架（如果你已经过去了学习g曲线，这可能会或可能不适用）
4. 该框架提供的工具/方法/后端/平台要求将引入不必要的复杂性（YAGNI，使用无需业务需求的框架可能会增加支持成本你必须支持整个事情，包括未使用的功能）

Answer 3

不使用框架的主要优点之一是你可以在你的代码中拥有更多的灵活性。对于规模较小的项目，通常具有这种灵活性会更好。

Answer 4

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

而且在某种程度上，我必须同意。大多数框架并没有显着简化开发。特别是“MVC”框架关于抽象而非实用性。然而总有一些功能对日常工作有帮助。 ActiveRecord/ORM让人想起减少繁琐的手动工作。表单助手可能会这样做，但我还没有看到过一个非常有帮助的表单。

一般来说，我相信，一个框架提供的功能越多的库代码，生产力就越高。但在Zend框架的情况下，它的复杂性随机地变得渺茫。但是，请检查一些较小的框架。避免过于抽象。寻找脚手架工具，而不是图书馆。

Answer 5

• 某些框架需要shell访问才能部署。
• 可扩展性，我读过，切分是一个问题
• 如果性能是首要任务，框架往往执行放慢速度
• 并非所有熟悉MVC模式的开发人员，以便维护，如果开发商/淘汰项目的旋转可能是一个挑战。

Answer 6

我的恐惧一直是，当一个框架停止维护/更新（无论什么原因）时会发生什么？您的项目被锁定到框架支持的任何PHP/MySQL版本中。