我最近实现了几个类似大小的Web应用程序，其中一个使用了“框架”，其中一个我自己编写，但使用了一组现有（主要是开源）库来提供某些常见功能，否则我会使用框架。
我注意到以下内容：
根据这种个人经验，我得到的印象是框架的使用可能被视为长期应用程序可维护性的反模式。
这是真的吗？
答案 0 :(得分：6)
我认为这是非常主观的。在我看来，应用程序框架确实是一种反模式，特别是对于更大，更复杂的项目。我认为有两个原因。
我在框架中看到的最大问题是，通过使用框架，您放弃了控制权。 JB Nizet写道“没有人强迫你为应用程序的每个部分使用框架”，而且在这种情况下这很好，但不幸的是它通常不是。通常框架具有控件，你有回调或派生类，当你想要做一些非凡的事情时你就不能。
这变得更糟，因为一般来说，设计框架非常困难。框架越糟糕，它就越受限制，框架用户就越多。我见过的很多框架都有一些基本的限制，最终会以某种方式限制最终的应用程序。我不会说只有框架创建者应该受到指责，尝试创建一个不限制框架用户的框架只是一个非常困难的（如果不是不可能的话）任务。
但是，框架并非全都不好。如果您的项目非常适合框架并且不会超出框架，那么框架确实可以加速开发。应用程序中的小框架在他们只处理一个问题域时往往会简化事情，通常没有太多风险。但是在最终框架中，一方面增加了你可能不需要的复杂性，另一方面，将接口与引擎结合起来，限制了框架用户。
答案 1 :(得分：5)
不，事实并非如此。有很好的框架和糟糕的框架，并且有适合您正在开发的应用程序的框架和不适合此应用程序的框架。你只需要选择最适合这份工作的工具。不期待应用程序的复杂性不一定是框架的错误。它可能是你的，因为你没有为任务选择合适的框架。
无论选择何种框架，都没有人强迫您将其用于应用程序的每个部分。如果框架简化了90％的应用程序的开发，并使其对于剩下的10％而言过于复杂，那么就不要使用这些10％的框架。
答案 2 :(得分：1)
我不认为模式/反模式术语非常有用 - 它说的形容词与“好”和“坏”一样多。但我认为大多数框架都有严重的缺点。
首先，让我们定义框架是什么：
如果框架是一个人，那么它的座右铭可能是“不要打电话给我们，我们会打电话给你。”
根据定义，您不得不以适合框架的样式编写代码，而不是以适合应用程序的样式编写代码。除非这两种风格一致，否则已经出现了明显的问题。
最初设计框架时可能会考虑到特定问题，并且许多框架在解决该问题方面非常成功。但是，一旦初始问题得到解决，大多数框架都会继续增长，包含越来越多的功能，这些功能与原始问题只是模糊不清。
通常会看到一个Web框架，它也可以执行安全性，调整图像大小，提供控制反转或与数据库交互。该框架已经失去了重点，并试图成为每个人的一切。它现在既不方便也不高效，并且可能由于缺乏焦点而导致错误和不完整。
然后你最好选择一个可以做一件事的图书馆，而且做得好。