这个问题的重点是提取使用基于Web的框架的优缺点：例如Cake PHP，Zend，jQuery，ASP.NET。这个问题完全与语言无关。让我从“站在巨人的肩膀上 ” 的概念开始。

优点：

• 使开发人员 -通过采取将先前已采取100点的行代码的功能，并将它们压缩成一个简单的函数调用使开发人员能够更复杂的功能集成到他们的网站。
• 允许更快地开发应用程序-这与需要在很小的窗口中创建网站的人非常相关（有没有这样的例子？）
• 更低的成本 -允许程序员将节省的成本转嫁给客户，从而产生了一个全新的客户群，他们想要一个网站，但以前却负担不起更高的开发成本。

缺点：

• 失去理解 -依靠框架的功能，开发人员可能会失去对事物工作原理的了解（在幕后）。
• 配置悬崖-一旦您超出了框架的配置，生产率就会立即下降，在框架配置之外实现功能可能很困难。
• 开发人员无法自拔 -您（开发人员）必须按照开发人员希望您执行的方式进行操作。

我想知道人们对我的观点有何看法，是否有人不同意？另外，如果人们还有其他观点，我将不胜感激。

底线是：在框架配置之外实现功能可能很困难。

让我们逐个假设地进行这个假设。

失去理解-依靠框架的功能，开发人员可能会失去对事物工作原理的了解（在幕后）。

假。您将永远不会对事物的运作方式有所了解。框架不是神奇的。它们只是方便的代码，您无需自己编写。

信不信由你，您会使用框架犯错。您必须直接调试到最低的HTTP级别，才能了解您做错了什么。

您将永远不会忘记引擎盖下发生的事情。除非，当然，除非您的框架如此史诗和完美，以至您永远不会有问题。

配置悬崖-一旦您超出了框架的配置，生产率就会立即下降，可能难以在框架配置之外实现功能。

这毫无意义。

第一。在没有框架的情况下进行构建可以轻松完成一项大型编程任务，其中包括单元测试，调试，诊断，配置控制以及所有其他无价值的工作，这些工作都在重新构架框架中的内容。那“生产力”如何？

第二。在框架之外实现事物总是很繁重的工作，因为-糟糕-在框架之外实现事物总是很繁重的工作。它与花在学习和配置框架上的时间无关。在框架之外实施任何事情本质上都是困难的。

开发人员无法自拔-您（开发人员）必须按照[框架]开发人员希望您进行操作的方式进行操作。

正确。这通常是一件好事。始终如一地做事比按自己的个人喜好来做更有价值。它可能需要“学习”和“理解”，但是它们具有价值。

安全问题-为人们提供这些工具以快速开发具有专业外观的网站是潜在的风险，人们可以为欺诈性公司快速创建具有专业外观的网站。

什么？这与框架无关。欺诈是欺诈，与使用的工具无关。

缺点：最终可能会失去支持/失去人气

• 如果有两个Web框架基本上做相同的事情，而您的Web框架没有成功，则该项目很可能会失败。在这种情况下，您可以自己维护框架（开源），重写应用程序，或者不进行任何更新（封闭源代码）。
• 根据框架的不同，您可能被迫按照框架的发布时间表升级应用程序。落后太远可能会使您没有资格获得支持。没有框架，您可以按计划进行工作。（这取决于您是否需要/不需要支持）。

专业版：商业代码

• 框架使您不必担心繁琐的工作，而专注于直接为业务带来价值的代码。
• 有时（实际上是可行的）框架升级使您可以“免费”向用户提供新功能。尤其是自定义控件附带的框架（例如新版本可能提供某种搜索/过滤器的网格）。

优点

• 更快的开发时间
• 更少的错误
• 更快的共享开发
• 图书馆支持
• 轻松的数据库交互

缺点

• “装箱”到框架
• 想要扩展或修改核心行为时通常不灵活
• “厄运错误” –源自核心或底层体系结构的错误，无法很好地追溯到其起源。一个完美的例子是使用Grails时的Spring错误。

我主张除了最简单的项目外，对所有项目都使用框架。如果您需要将“联系我们”表单添加到现有的HTML站点，则可以使用一个PHP文件而不是移动到框架。

我想到的几件事是...

优点

• 代码重用-通过使用框架，您正在重用经过测试且正确的代码。
• 快速开发/原型制作。
• （通常）可以被认为是安全的集成输入验证（假设开发人员正确使用了它）

缺点

• 失去支持。这里想到的是Symfony 1.4。我想Symfony将在相当长的一段时间内支持1.4，但是知道2.0不是向后兼容的，因此1.4在未来几年中似乎是一个支持的死胡同。
• 高架; 通过使用框架，您正在运行数千行，这些行可能不适用于您的特定应用程序，但适用于其他应用程序。有些人认为这是一个合理的权衡，有些人选择从头开始编写代码以提高性能。
• 为您的特定需求使用错误的框架。并非所有框架都是平等创建的。

这完全取决于您使用的框架。

如果您使用的是ASP.NET，那么您将处于劣势：充其量只是一种漏水的抽象，而在最坏的情况下，做一些在其他框架中琐碎的事情却很难掩盖事实，在网络上工作。

ASP.NET MVC试图解决该问题，并且效果很好。

存在框架，因此我们可以花更多的时间完成工作，而花更少的时间构建脚手架。在这方面，除非您真的想花时间建造脚手架，否则我认为没有任何不利之处。

我想补充一点。

• 我发现框架的最大问题之一是人们停止思考。他们只是想使用框架，因为它很酷，或者因为他们总是使用框架。他们不停地思考使用是否合理。
• 许可，人们似乎只是在使用框架而没有真正看一下许可。这可能会导致他们没有意识到。或考虑更改许可证时会发生什么。
• 使用许多相同类型的框架。有时，它们可能是实际上可以做几乎相同事情的许多框架。作为一家公司，您会做出明智的选择，并且每个项目都没有不同的框架。
• 跟上新版本可能是一个挑战

我仍然认为，在考虑优点时，值得付出更多的努力来评估框架，评估许可证，按使用情况保留框架的清晰清单以及采用智能版本控制策略。

优点：

• 当您持续使用框架时，对于已经在您的项目上工作的人来说，项目的学习时间就会减少。
• 自己更快的发展
• 您自己的授权开发人员

我是根据过去13年的个人经历讲的。在我的公司中，我们使用了支撑杆，经过短暂的弯弯后感觉很棒。在我的下一个文章中，我们使用的架构几乎是不透明的，虽然有些像Struts，但是已经成长了，我们可以扩展它，但是核心代码只是jars。等等。在过去的3年中，我们一直在一家小型公司（dev <30的公司）工作，这都是我们自己的jsps，servlet和ejbs。考虑到我们的多个客户和jsps的重复，2012年将制作一个模拟struts2的j2ee过滤器。为什么不使用stuts 2？我希望我们有，但是：无法通过我们的首席设计师；没有足够的经验或时间。

因此，我们有一些拦截器，这些拦截器是我们的小型框架使用的。现在，当我有时间阅读《 struts 2》这本书时，我发现我们错过了太多！

我们确实使用了一些很棒的算法，缓存和UI，但是已经浪费了很多时间，并且负担了很多代码，而我们有3年的计划要退休。