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

Question

我最近实现了几个类似大小的Web应用程序,其中一个使用了"框架",其中一个我自己编写,但使用了一组现有的(主要是开源)库来提供某些常见的功能,否则我会使用了一个框架.

我注意到以下几点:

• 基于框架的应用程序当然可以更快地设置 - 它有效地"开箱即用".然而,随着时间的推移,随着更多功能的增加,维护起来变得越来越复杂.一旦我需要一些不适合框架的东西,我发现自己被迫采取一些丑陋的解决方法.
• 基于库的应用程序在开始时需要更多代码来引入和集成必要的库,即必须在开头编写合理数量的粘合代码.但随着时间的推移,它变得更容易扩展和重新计算,因为框架设计中不需要任何限制.

根据这种个人经验,我得到的印象是框架的使用可能被视为长期应用程序可维护性的反模式.

这是真的吗？

Answer 1

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

我在框架中看到的最大问题是,通过使用框架,您放弃了控制.JB Nizet写道"没有人强迫你为应用程序的每个部分使用框架",而且在这种情况下这很好,但不幸的是它通常不是.通常框架具有控件,您有回调或派生类,当您想要做一些非凡的事情时,您不能.

这会变得更糟,因为一般来说,设计框架非常困难.框架越糟糕,它就越受限制,框架用户就越多.我见过的很多框架都有一些基本的限制,最终会以某种方式限制最终的应用程序.我不会说只有框架创建者应该受到指责,尝试创建一个不限制框架用户的框架只是一个非常困难的(如果不是不可能的话)任务.

但是,框架并不全是坏事.如果您的项目非常适合框架并且不会超出框架,那么框架确实可以加快开发速度.应用程序中的小框架在他们只处理一个问题域时往往会简化事情,通常没有太多的风险.但是在最终框架中,一方面增加了您可能不需要的复杂性,另一方面,将接口与引擎耦合在一起,限制了框架用户.

Answer 2

不,事实并非如此.有很好的框架和糟糕的框架,并且有适合您正在开发的应用程序的框架和不适合此应用程序的框架.你只需要选择最适合这份工作的工具.不期待应用程序的复杂性不一定是框架的错误.它可能是你的,因为你没有为任务选择合适的框架.

无论选择何种框架,都没有人强迫您将其用于应用程序的每个部分.如果框架简化了90%的应用程序的开发,并使其对于剩下的10%而言过于复杂,那么就不要使用这些10%的框架.