不使用Java Web框架，改善生活？

Question

我已经厌倦了每天都要学习一种新的Java Web框架。JSP、Struts、Wicket、JSF、JBoss Seam和Spring MVC只是其中几个，所有这些无数的框架都试图解决同样的问题。然而，它们中没有一个真正解决了根本性问题-这就是为什么总是不断出现新的。

大多数框架在第一印象上看起来非常光鲜亮丽，因为它们简化了简单事物的处理方式。但是，一旦涉及实际应用案例的实现，就会遇到问题。通常，这些框架没有提供任何帮助，反而妨碍并通过强制按照框架自己的逻辑和环境实现限制选项。

简而言之，在使用框架时，我看到以下缺点：

1. 大多数框架的学习曲线较陡峭，您需要先理解有时相当学术的概念，并知道一堆配置文件的含义和位置，然后才能开始使用。
2. 文档通常更或多或少糟糕，缺少公开可访问的在线参考资料，过时无力，混淆不兼容的不同版本，或者所有这些都缺少有用的示例。
3. 框架由大量类组成，使得仅通过浏览源代码就几乎无法理解其预期使用方式。
4. 因此，您需要购买一些"XYZ在21天内愚蠢地行动"类型的书籍，它们具有糟糕的用户界面，因为它们缺少全文搜索，并且难以携带。
5. 要真正使用其中一个框架，您需要牢记如何按照框架所需的方式完成任务，通过记忆适当的类和方法名称直到头部充满了愚蠢而无用的信息。
6. 这会导致大量开销，降低应用程序的性能，并在尝试理解实际情况时使您的大脑感到麻木。
7. 在现实世界中，通常没有时间熟悉新事物，因为需要快速生产。由于这种学以致用的方法，人们总是只寻找完成下一个任务的最快方法，而不是真正理解新工具及其可能性。

在我看来，认为遵循标准可以让新加入项目的人很快开始工作这个论点是无效的，因为即使在同一家公司内，每个项目都使用不同的框架（至少在我的情况下）。

我觉得阿尔伯特·爱因斯坦的以下话语非常适用于这里：

“我们不能用创造问题时采用的思维方式来解决问题。”

回到我美好的 PHP 编码时代，当编码仍然有趣和高效的时候，我通常会为大多数事情编写自己的框架，并将它们从一个项目复制并调整到另一个项目。
这种方法非常成功，导致快速开发，没有任何开销，并且实际上比大多数 Java 框架更强大，只有几百行代码的单个文件加上一些简单的 mod_rewrite 规则。
这当然不能解决 Web 开发的所有问题，但它简单、快速并且直截了当。
虽然完全适合当前项目的要求，但它也易于扩展并具有零开销，因此性能非常高。

那么为什么要使用这些框架，而不是把它们都扔掉并回到根本呢？
当我们明天又开始使用新框架的下一个项目时，我应该对老板说什么？
还是有一些真正有所不同的框架吗？
或者我忽略了什么隐藏的好处？

- dankoliver

---

听起来你已经准备好转换到 Ruby on Rails 了！ - John Topley

随你喜欢。但是我更喜欢利用经过数百万人工时的辛勤工作，使用经过试验、测试、证明和广泛理解的框架来提供高度可配置的解决复杂问题的方案，这可以让我专注于我的问题领域。 - j pimmel

你应该看看 Stripes 框架 :) - ScArcher2

很有趣：我发现有人在几个答案中提到了这个观点，即比起我可能花更多时间去做一件事情。 但是，这是什么样的指标呢？ 以工作时间来衡量质量和按每天代码行数付费一样愚蠢。 如果所有时间都只是用来进一步扩大已经包含1000多个类的框架，增加复杂性，在这种情况下如何提高质量？ - dankoliver

为什么不将你的框架移植到Java呢？ - Thorbjørn Ravn Andersen

Answer 1

在我使用 PHP 编程的黄金时代，当编码仍然很有趣和高效时，我经常为大多数东西编写自己的框架，并将其从一个项目复制并采用到下一个项目中。这种方法非常成功，导致开发速度快，没有任何开销，并且实际上比大多数 Java 框架更强大。

请原谅我不会相信这个说法。

但是只有几百行代码放在单个文件加上一些简单的 mod_rewrite 规则。这肯定没有解决 Web 开发的所有问题，但它简单、快速且直截了当。

因此，基本上你开发了自己的框架，经过数月或数年的时间进行了定制，可以非常快速地使用它，因为你对它非常熟悉。

然而，您却无法理解为什么其他人也要这样做，并尝试将结果转化为每个人都能使用的东西？

那么，您开发的这个伟大的框架在哪里？如果它如此强大且易于使用，那么专门的社区、成千上万的用户和数百个使用它的网站在哪里呢？

每个项目甚至在同一家公司内部都使用不同的框架（至少在我的情况下），这就是你的问题所在。为什么每个项目之后都要放弃获得的每个框架专业知识呢？

想法是选择一个框架，并在多个项目中坚持使用它，以便您能够精通它。您必须投入一些时间学习框架，然后它可以通过允许您在更高级别上工作来节省时间。

- Michael Borgwardt

---

我参与了太多这样的项目，人们认为编写他们自己的控制器、自己的ORM解决方案，或许是自己的小型模板语言都是好主意。在我看来，即使是一个质量不佳但标准化的抽象层，从裸 PHP 或 Servlets 开始也很有帮助。+1 - Henning

我敢打赌，那个开发自己框架的人可能会认为“哇，这很好用！”但他的同事们或者接下来需要操作这段代码的任何人最终会想：“这家伙又重新发明轮子了...” - matt b

你没有抓住重点。 自己的解决方案的优势在于它不试图涵盖所有的网络应用需求，因此它不能作为通用框架使用。 相比于一个可以做任何事情但无法解释如何使用的全能框架，设计一个单一目的的解决方案要简单得多，并且容易处理好并消除漏洞。 - dankoliver

你最终仍然会重复造轮子（即重新做出糟糕的设计决策，重新实现和修复错误），而“神框架”早已解决了许多方面的问题。总的来说，除非你在处理微小项目或极不常规的项目，否则通过学习和使用好的框架比自己动手节省大量时间并获得更好的质量。无论你内心如何倾向于野蛮编码。 - Michael Borgwardt

“选择一个框架并坚持使用”这个想法很好，但它是否奏效呢？不同的项目有不同的要求。如果有一个万能的框架，为什么不所有人都在使用它呢？ - dankoliver

Answer 2

自己开发框架的问题在于，你会犯所有已经出现并解决的传统框架犯过的错误，特别是在安全方面。

只需要问问Jeff和他的团队，在实施Stack Overflow中的WMD时必须考虑什么就能知道这一点。我宁愿在项目中使用他们已经生产的东西，而不是从头开始实现。这只是一个例子。

- Martin OConnor

---

如果你不加思考，就会重蹈已被解决的所有成熟框架已经犯过的错误。我希望我可以为此投多票。 - matt b

当然，在开发自己的解决方案时，我也需要应对同样的问题。但是，我可以根据我的项目需求选择最适合的方式来解决这些问题，而无需过多地进行泛化。 我只实现我真正需要的部分，而不是实现以后可能有人需要的全部功能，因此我的解决方案更简单，并且更容易保证安全性。 - dankoliver

问题在于你可能会犯一些不明显的错误，除非有经验的人指出，否则你甚至可能不知道存在任何问题。再次以安全为例，很难自己做到完美。 - Martin OConnor

“人生中最大的错误就是不断担心自己会犯错。” ~艾伯特·哈伯德我坚持认为，相比于复杂的框架，盲目信任并不深入了解的框架更加危险，因为你只需要使用其中一小部分功能。 - dankoliver

Answer 3

以下是来自Kev在“What’s your most controversial programming opinion?”话题中的一段引言，与此处非常契合：

我认为整个“企业”框架的概念是虚伪的。J2EE、.NET、大多数Apache框架和管理此类事物的大多数抽象都会产生比它们解决的问题更多的复杂性。

拿任何常规的Java或.NET ORM，或者任何所谓的现代MVC框架，它们都会进行“魔法”以解决繁琐、简单的任务。你最终会写大量丑陋的XML样板代码，很难验证和快速编写。你有巨大的API，在这些API中，有一半只是为了集成其他API的工作，还有无法回收利用的接口和只需要克服Java和C#的不灵活性才需要的抽象类。我们根本不需要其中大部分。

还有所有不同的应用服务器，以及它们自己的描述符语法，过于复杂的数据库和团队产品呢？

这里的重点不是说复杂性==坏，而是不必要的复杂性==坏。我曾在大型企业安装中工作过，其中一些是必要的，但即使在大多数情况下，一些自制脚本和简单的Web前端也足以解决大多数用例。

我会尝试将所有这些“企业化”应用程序替换为简单的Web框架、开源数据库和微不足道的编程结构。

- dankoliver

Answer 4

问题当然不仅仅出现在Java框架上。我已经数不清有多少个C++ MFC项目试图将它们的需求塞进文档/视图模型中而陷入困境（这种模型只适用于文本和图形编辑器，对于数据库应用程序来说特别困难）。

成功使用框架的秘诀是改变你的应用程序以匹配框架，而不是相反。如果你做不到这一点，甚至不要考虑使用框架——最终会比你使用一些好的、可靠的、文档完善的实用库从头开始编写应用程序更费力。

- anon

---

+1：好观点。要么选择一个框架，然后构建应用程序以匹配该框架，要么选择与您的架构相匹配的框架。如果将应用程序强行塞入框架中会导致巨大的阻抗不匹配，这是失败的原因。 - D.Shawley

Answer 5

你是说我们每次想要构建Web应用程序都应该使用套接字和HTTP吗？

Servlet容器本身可以被视为一个框架，因为它处理所有这些混乱的细节，使您只需要编写更简单的Servlets/Filters/Listeners（即针对您的应用程序特定的“扩展”框架）。

任何框架试图做的就是将单调、可重复、易出错的基础代码与有趣的应用程序特定代码分离开来。

然而，对于小型应用程序，您可以采用仅使用JSP和Servlet的Model 2 MVC方法。

例如：

class MyController extends HttpServlet {
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ... {
        MyBean model = // do something
        request.setAttribute("model", model);
        request.getRequestDispatcher("/view.jsp").forward(request, response);
    }
}

随着您的应用程序变得更加复杂，您可以考虑使用Spring MVC来提供控制器、视图解析器等的松耦合（因此更灵活）。

- toolkit

---

模型2听起来很有趣。我一直在使用Spring MVC并享受框架的设计，但是我想知道除了Spring注入之外它能给你多少东西（相对于模型2）？关于该模式的详细信息似乎比较少，但我找到了这篇文章：http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html - James McMahon

Answer 6

当面对又一个无法胜任的框架时，我能感同身受。

经历了十年的jsp、struts、EJB、EJB2、struts2、jsf，最近还有所有新的web服务框架、xslt恐怖和wsdl-first噩梦，我已经厌倦了。

框架存在许多问题。它们会泄漏信息，所以你需要学习更多，内部框架成本巨大，使用外部框架也很贵（但比较少），因为它们很少提供实际帮助，最后你只能编写大量的xml配置，并花费数天时间来纠正大小写和拼写错误，而这些错误在你喜欢的代码编辑器中立即就能看到。

也许答案是找到一些不那么浮夸的工具包，它们试图解决问题，而不是重新定义世界，但这也很难，因为基本的应用模型（html over http）本身就很尴尬。

添加的事实是似乎有很多使问题复杂化的人，这些人似乎着迷于将无聊的简单问题转化为复杂（但困难）的有趣问题（也许是Eric Sink上面提到的软件开发公理的一个变体）。

加上开发者自以为是的傲慢态度，他们认为自己什么都知道，并毫不犹豫地编写新框架来解决所有难题，只剩下10％，现在更难以解决。

我没有.NET经验，但.NET世界似乎没有那么多的理论家和复杂化者，也许VB的余味让他们感到害怕，但每次我听到有人告诉我他们花了1500个小时在他们的maven配置上（你好吗？），我都在认真考虑从我的简历中删除“java”。

...问题是什么？有哪些框架可以产生差异？

编辑-添加条纹和QueryDSL。

我建议尝试使用Stripes或GWT，搭配QueryDSL + Hibernate或OpenJPA（带注释），因为你实际上是在开发Java应用程序，尽量限制使用基于wsdl的web服务、以xml为中心的框架、EJB和ESB（不是啤酒）。

- KarlP

---

你尝试过Spring Web Flow吗？我承认，你创建的流程定义都是在XML中，但它们通常非常小，并且语法实际上相当合理。它使用XML中的特定领域语言，并将Web应用程序流建模为由状态（视图、操作、决策、子流、结束）和它们之间的转换组成的状态机。来看一下吧。 - InverseFalcon

在Maven配置上花费1500小时，哈哈，加一分。 - zaf

谢谢这个建议。我怀疑我会喜欢使用又一个用XML表达的领域特定语言来工作。 - KarlP

Answer 7

我曾经参与了一个使用JSF实现的项目，那是一场噩梦。

大部分时间都花在了让代码可以编译上，而实际运行起来有一半以上是无法正常工作的。几乎没有什么教程可供参考，唯一的文档只是自动导出的源代码，没有任何人性化的注释。这样的条件怎么能让人们顺利开展工作呢？

我们看到的几个框架中，只有Sun的JSF能够创建一个可以编译的新项目！其他的框架只能生成一堆东西，需要花费数天时间才能达到可编译的状态。

网络上几乎没有信息。每次搜索，最多也只有20页的搜索结果，其中只有前1-3页有用。在那些有用的信息中，一半的人在哭求帮助，另一半则表示他们曾经寻求过帮助，但得不到任何人的回应。最终，他们失去了时间和兴趣，放弃了这项技术。

于是我们只能耗费很长时间，最终制作出了一些简单的东西，这本来只需要用ASP.NET等其他技术几周时间就能完成。

之后我们开始探索JSF的替代框架。但让我们惊讶的是，它们都非常不兼容。

毫不意外的是，我们也加入了放弃JSF的人的行列。

- User

---

JSF并不太糟糕...只要你试着将其限制在视图中。我尽量远离阶段监听器、组件绑定、自定义转换器、托管bean和可怕的导航。我使用Spring进行IoC和Spring Web Flow进行控制器。到目前为止，SWF是我见过最明智的Web框架...虽然我必须承认我唯一的其他经验是使用Servlets、Struts和JSF。 - InverseFalcon

Answer 8

考虑反面论点。我目前在一家商店工作，除了JSP标准之外，我们不使用任何框架。每个人做事的方式都不同，而且我们对于解耦和验证等安全问题非常宽松。

虽然我认为使用框架并不会自动使你成为更好的程序员，但我认为通过使用大多数框架实现的标准设计模式，并且通过轻松访问诸如验证之类的实用函数，我认为你将被迫编写到一定的标准。

在 Web 应用程序设计中，你并不是每次都要重新发明轮子，所以你要么最终要构建自己的通用任务解决方案，要么使用框架。我认为通过使用通用框架，而不是构建自己的框架，你将获得经过充分测试和灵活的底层代码。

构建自己的解决方案作为学术追求没有错，但我接受这样一个事实，即有人花费了比我更多的时间开发一个强大的解决方案。例如，log4j，很容易滚动你的记录器，但是log4j经过了充分的测试和维护，并且他们花费了时间来改进灵活性和性能，这是大多数自己研发的记录器所不能匹敌的。最终结果是一个强大而简单的框架，甚至可以在最基本的应用程序中使用。

- James McMahon

Answer 9

我的建议是：你不应该只是学习听到的任何web框架，而是要看一看它，看看它是否让你编码舒适，询问在stackoverflow或论坛上了解它的优缺点，然后好好学习并坚持使用它，直到你感到它已经过时或者有问题。您所写的任何web框架本身都很好，如果您“真正”知道它的作用，则可以很愉快地使用它。如果您不知道，您就像在沙漠中漫无目的地行走！我还发现，21天的书绝对不是掌握框架或技术的可靠方法。文档肯定是在采用一个框架时要考虑的东西，如果您自己查看代码也会有帮助（实际上，当我遇到一些我认为奇怪的行为时，这就是最有帮助的）。

1-那么，为什么要使用这些框架，而不是把它们全部丢掉，回到基础上呢？

如果回到基础，你将重新编写重复的代码，并且大多数这些框架都是开源的，这意味着它们可能比你独自维护自己的框架更好。

2-当我们明天开始使用新框架开展下一个项目时，我应该对老板说什么？

这是我第一次使用这个框架，我不知道为什么我们应该使用这个框架，我已经知道X并且我非常擅长它。请记住我学习这个框架的成本，由于我对这样的框架的无知而必须重新工作的成本。如果我们使用X，我认为我们会更好，如果这是一个具体要求，我们应该为此而战，并只在真正必须时才使用它，说明前面的注意事项。

那么，也许有些框架真的有所不同吗？

只有那些处理你思考方式而不是编写代码方式的框架（Think Struts在其黄金时期强制实施MVC模式）。

还有一些我忽视的隐藏优势吗？

实话实说，想不出来。

- MahdeTo

---

维护...选择那些有规范支持的框架。 - Thorbjørn Ravn Andersen

Answer 10

在 PHP 中，你会遇到同样的问题：有太多框架可供选择，每个都声称是最好的（虽然你可以从一些方面来区分它们：纯 PHP5 设计与 PHP4 兼容性、Rails 哲学（不灵活的文件夹层次结构、自动生成的代码）与库方法等），你花费的时间比写代码还要多，只是为了寻找和探索可能性！
但是在 PHP 中，它允许预先解决常见问题，如 I18N 支持、插件集成、会话和身份验证管理、数据库抽象、模板、Ajax 支持等。避免在每个项目中重新发明轮子，并避免新手常见的陷阱。

当然，对于 Java 框架也有一些提示：大型还是小型？文档是否完善？是否广泛使用？是否适用于 XML 爱好者？等等。
我想大多数框架都针对大型项目，学习时间不是一个大问题，可扩展性和部署的易用性很重要等。它们可能对小型项目来说过于复杂。

这些框架还有一个趋势，即旨在实现一组一致的松散耦合库，而不是一个庞大的框架。在 PHP 世界中，Zend 框架就是这种情况（有些人甚至否认使用“框架”这个词……）。
因此，它解决了“解决常见问题”的问题，而不会妨碍你的工作。

- PhiLho

---

“解决常见问题而不妨碍过程” - 我认为这是一个非常好的观点！这正是我在使用过的Java框架中感到烦恼的地方，它们总是妨碍我的工作！在Java世界中，我经常发现一种特定的傲慢态度：Sun的Java架构师以及许多框架程序员似乎认为他们比你更懂，因此强迫你按照某种方式做事，而不是给你可以按你自己或需要的方式使用的工具。 - dankoliver