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

Question

我最近实现了几个类似规模的Web应用程序，其中一个使用了“框架”，而另一个则是我自己编写的，但使用了一组现有（大多数是开源）库来提供某些常见功能，否则我会使用框架。

我注意到以下内容：

- 基于框架的应用程序确实更快地设置 - 它有效地“开箱即用”。然而，随着时间的推移，并添加更多功能，它开始变得越来越复杂。一旦我需要的东西不符合框架，那么我就不得不采取一些丑陋的解决方法。 - 基于库的应用程序在开始时需要更多的代码来引入和集成必要的库，即需要编写相当数量的粘合代码。但是，随着时间的推移，它更容易扩展和重构，因为没有任何约束需要符合框架设计。

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

这是真的吗？

- mikera

Answer 1

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

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

这变得更糟，因为一般来说，设计一个框架非常困难。框架越差，限制就越多，越妨碍框架用户。我见过很多框架都有一些根本性的限制，最终会以某种方式限制最终的应用程序。我不会说只有框架创建者有责任，尝试创建一个不限制框架用户的框架可能是非常困难，甚至是不可能的任务。

然而，框架并非全是坏处。如果您的项目与框架相匹配，并且不会超出框架范围，框架确实可以加速开发。应用程序中的小型框架也往往会简化事情，因为它们只处理一个问题域，并且通常没有过多的风险。但最终，框架一方面增加了您可能不需要的复杂性，另一方面将接口与引擎耦合在一起，限制了框架用户。

- Antti

Answer 2

不，事实并非如此。存在好的框架和坏的框架，而且有些框架适合你正在开发的应用程序，而有些则不适合。你只需要选择最适合任务的最佳工具。如果没有预见到应用程序的复杂性，并不一定是框架的错。这可能是你的问题，因为你只是没有选择适当的框架来完成任务。

不管选择的框架是什么，没有人强迫你在应用程序的每个部分都使用它。如果框架可以使90%的应用程序开发变得简单，但对剩下的10%太复杂，那就别在这10%中使用该框架。

- JB Nizet

---

这正是我最初想的，但这不是预设应用程序的范围/复杂性已知，以便选择正确的框架，至少达到90%的水平吗？根据我的经验，你很少有那种保证的奢侈。 - mikera

@mikera - 我同意这种观点，即存在好的和坏的框架，并且好坏是相对于你的应用程序而言的。如果你甚至怀疑你的应用程序将来可能需要一些奇怪的功能，那么选择不会干扰的框架就是你的责任。只要防御性地选择你的工具，就可以了（我想）。 - cji

Answer 3

我认为“模式/反模式”这个术语并不是很有用 - 它所表达的跟“好”和“坏”形容词差不多。但我确实认为大多数框架存在严重的缺陷。

首先，我们来定义一下什么是框架：

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

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

那么按照定义，你被迫以适合框架的风格编写自己的代码，而不是适合应用程序的风格。除非这两种风格能够对齐，否则已经存在明显的问题。

一个框架最初可能是针对特定问题设计的，许多框架在解决这个问题方面非常成功。然而，一旦初始问题得到解决，大多数框架都倾向于继续扩展，涵盖与初始问题只有模糊关系的越来越多的功能。

一个 Web 框架也许可以做安全、调整图像大小、提供控制反转或与数据库交互。框架失去了它的焦点，试图成为每个人的一切。它现在既不方便也不高效，可能由于缺乏焦点而存在漏洞和不完整。

然后你最好选择一个只做一件事情并且做得很好的库。

- Joakim Ahnfelt-Rønne

Answer 4

框架的整个定义是一种基本结构，所有东西都基于它，这与模块化直接相反。它也可能违反第三方或特定领域的解决方案。

- Eyso