Design patterns 应用程序框架是反模式吗？

我最近实现了两个大小类似的web应用程序，其中一个使用了“框架”，另一个我自己编写，但使用了一组现有的（大部分是开源的）库来提供一些我本来会使用框架的常见功能

我注意到以下几点：

• 基于框架的应用程序当然设置得更快-它有效地“开箱即用”。然而，随着时间的推移，随着更多功能的添加，维护变得越来越复杂。当我需要一些不符合框架的东西时，我发现自己不得不求助于一些丑陋的变通方法
• 基于库的应用程序在开始时需要更多的代码来引入和集成必要的库，即在开始时需要编写合理数量的粘合代码。但随着时间的推移，它变得更容易扩展和重新考虑，因为不存在因需要适应框架设计而带来的任何约束

从这段个人经历中，我得到的印象是，使用框架可能被认为是长期应用程序可维护性的反模式

---

真的是这样吗？不，不是这样。有好的框架也有坏的框架，有适合你正在开发的应用的框架，也有不适合这个应用的框架。你只需要为这项工作挑选最好的工具。没有预见到应用程序的复杂性并不一定是框架的错。它可能是您的，因为您没有为任务选择合适的框架

---

无论所选择的框架是什么，没有人强迫您将其用于应用程序的每个部分。如果框架简化了90%应用程序的开发，并且使其对于剩下的10%应用程序来说过于复杂，那么就不要对这10%应用程序使用框架。

我认为这是非常主观的。在我看来，应用程序框架确实是一种反模式，特别是对于更大、更复杂的项目。我认为有两个原因

我看到的框架最大的问题是，使用框架会放弃控制。JB Nizet写道“没有人强迫您对应用程序的每个部分都使用框架”，在这种情况下这很好，但不幸的是，通常不是这样。通常框架有控制权，你有回调或派生类，当你想做一些不同寻常的事情时，你不能

这变得更糟，因为一般来说，很难设计好一个框架。框架越差，限制就越大，对框架用户的影响就越大。我见过的许多框架都有一些基本的限制，最终以某种方式限制了最终的应用程序。我不会说只有框架创建者才是罪魁祸首，尝试创建一个不限制框架用户的框架是一项非常困难的任务，如果不是不可能的话

---

不过，框架并不都是坏的。如果您的项目很适合框架，并且不会超出框架，那么框架确实会加快开发速度。当应用程序中的小框架只处理一个问题域时，它们也倾向于简化事情，通常不会有太多阻碍的风险。但最终框架，一方面，增加了您可能不需要的复杂性，另一方面，将界面与引擎结合起来，限制了框架用户。

我认为模式/反模式术语并不是很有用——它说的和形容词“好”和“坏”一样多。但我确实认为大多数框架都有严重的缺点

首先，让我们定义什么是框架：

• 框架提供回调或类似的机制，您可以连接到自己的代码。您自己的大部分代码都在这些回调中运行

如果一个框架是一个人，它的座右铭可能是“不要打电话给我们，我们会打电话给你。”

根据定义，您必须以适合框架的风格编写代码，而不是以适合应用程序的风格编写代码。除非这两种样式对齐，否则已经存在一个明显的问题

一个框架在设计之初可能会考虑到一个特定的问题，许多框架在解决这个问题方面都相当成功。然而，一旦最初的问题得到解决，大多数框架往往会不断增长，包含越来越多只与原始问题模糊相关的功能

web框架也可以实现安全性、调整图像大小、提供控制反转或与数据库交互，这种情况并不少见。该框架已经失去了它的焦点，并试图成为每个人的一切。现在它既不方便也不高效，而且可能由于缺乏重点而充满bug和不完整

---

然后你最好使用一个做一件事并且做得很好的库。

这就是我最初的想法，但这不是预先假设应用程序的范围/复杂性是已知的，以便选择正确的框架，至少达到90%的水平吗？根据我的经验，你很少有这种保证的奢侈…@mikera-我同意有好的框架和坏的框架，好的或坏的框架与你的应用程序有关。如果您甚至怀疑您的应用程序将来可能需要一些奇怪的功能，那么您有责任选择不会干扰的框架。只要选择你的防守工具，这就是一切（我想）。