不使用Java Web框架让生活更美好？

Question

我已经厌倦了每隔一天必须学习另一个Java Web框架.
JSP,Struts,Wicket,JSF,JBoss Seam,Spring MVC仅举几例 - 所有这些无数的框架试图解决同样的问题.然而,它们都没有真正解决根本问题 - 这就是为什么仍然会出现越来越多的新问题.

大多数人在第一印象时看起来非常明亮和闪亮,因为它们简化了做简单的事情.
但是,一旦涉及到实际用例的实现,就会遇到问题.
通常,框架不提供任何帮助,但是通过强制根据框架自己的逻辑和环境实现事物来阻碍一个并限制选项.

简而言之,我在使用框架时会看到以下缺点:

1. 大多数情况都是陡峭的学习曲线,在开始之前,您首先需要了解一些相当理论的概念,并了解一堆配置文件的含义和位置.
2. 文档通常或多或少可怕,要么缺少公共可访问的在线参考,无助过时,将不同的不兼容版本或所有这些混淆在一起,并且通常不提供任何有用的示例.
3. 该框架由数以万计的类组成,这使得仅通过浏览源来实际理解预期用途是不可能的.
4. 因此,您需要购买一些"21天内用于假人的XYZ"书籍,这些书籍的用户界面很差,因为他们缺少全文搜索并且携带很多.
5. 要真正使用这个框架中的一个,你需要通过记住适当的类和方法名称来记住框架需要它的方式,通过记住适当的类和方法名称,直到你的头脑充满了你不能用于其他任何东西的愚蠢和无用的信息. .
6. 有一个很大的开销,减慢你的应用程序性能,并在试图了解真正发生的事情时让你的大脑感到麻木.
7. 在现实世界中,由于生产力的压力,通常没有时间熟悉新事物.通过这种学习方法的结果,人们总是只寻找完成下一个任务的最快方法,而不是真正理解新工具及其可能性.
8. 遵循标准的论点允许新项目的人快速入门在我的视图中无效,因为每个项目甚至在同一公司内使用不同的框架(至少在我的情况下).

在我看来,阿尔伯特·爱因斯坦的以下引用非常适合这里:

"我们无法通过使用我们在创建问题时使用的相同思维来解决问题."

回到我早期的PHP编码日,当编码仍然充满乐趣和高效时,我曾经为大多数事情编写自己的框架,只是复制粘贴并将它们从一个项目中采用到下一个项目.
这种方法得到了很好的支持,导致了快速开发,没有任何开销,并且实际上比大多数Java框架更强大的框架,但在单个文件中只有几百行代码加上一些简单的mod_rewrite规则.
这当然不能解决Web开发的所有问题,但它简单,快速,直接.
虽然完美地适应了当前项目的要求,但它也很容易扩展,并且由于零开销而具有非常高的性能.

那么为什么所有那些使用这个框架的麻烦,为什么不抛弃它们并回到根源呢？
当我们明天再次使用新框架启动下一个项目时,我应该对我的老板说些什么？
或者是否有可能真正有所作为的框架？
或者我忽略了一些隐藏的优势？

Answer 1

回到我早期的PHP编码日,当编码仍然充满乐趣和高效时,我曾经为大多数事情编写自己的框架,只是复制粘贴并将它们从一个项目中采用到下一个项目.这种方法得到了很好的支持,导致了快速开发,没有任何开销,并且实际上比大多数Java框架更强大的框架

原谅我相信不是一秒钟.

但是在单个文件中只有几百行代码加上一些简单的mod_rewrite规则.这当然不能解决Web开发的所有问题,但它简单,快速,直接.

所以基本上你在几个月或几年的时间里开发了自己的框架,根据自己的需要量身定制,并且可以非常快速地使用它,因为你非常了解它.

然而,你无法理解为什么其他人会这样做,然后尝试将结果转化为可供每个人使用的东西？

你开发的这个伟大的框架在哪里？如果它功能强大且易于使用,那么专用社区,成千上万的用户和数百个用它开发的网站在哪里？

即使在同一家公司内,每个项目都使用不同的框架(至少在我的情况下)

好吧,那就是你的问题.为什么你会抛弃每个项目后每个框架获得的专业知识？

我们的想法是选择一个框架并在多个项目中坚持使用,以便您熟练掌握它.您必须花一些时间来学习框架,然后通过允许您在更高级别上工作来节省您的时间.

Answer 2

提出自己的框架的问题在于,您将犯下所有已建立的框架已经偶然发现并解决的所有相同错误.在安全方面尤其如此.

只要问Jeff和他们在堆栈溢出中实现WMD时必须考虑的问题.我宁愿使用他们在项目中生成的东西,而不是从头开始实现它.这只是一个例子.

Answer 3

以下是来自线程的Kev引用什么是你最有争议的编程观点？哪个适合在这里非常好:

我认为整个"企业"框架的事情是烟雾缭绕.J2EE,.NET,大多数Apache框架和管理此类事物的大多数抽象都会产生比它们解决的复杂性更高的复杂性.

采用任何常规的Java或.NET OMR,或任何所谓的现代MVC框架,这些框架可以"魔术"来解决繁琐,简单的任务.您最终会编写大量难以验证和快速编写的丑陋XML样板.您拥有大量的API,其中一半只是为了集成其他API的工作,无法回收的接口,以及仅为克服Java和C#的不灵活性所需的抽象类.我们根本不需要大部分内容.

所有不同的应用程序服务器如何使用自己的darned描述符语法,过于复杂的数据库和组件产品？

这一点的重点不在于复杂性==糟糕,而是不必要的复杂性==糟糕.我曾经在大规模的企业安装中工作,其中一些是必要的,但即使在大多数情况下,一些本土的脚本和一个简单的Web前端就是解决大多数用例所需的全部内容.

我试图用简单的Web框架,开源数据库和简单的编程结构替换所有这些企业应用程序.

Answer 4

问题当然不仅仅是Java框架.我已经失去了我所看到的C++ MFC项目的数量,他们试图将他们的需求转化为文档/视图模型(实际上只是文本和图形编辑器的工作 - 数据库应用程序特别难以制作) .

成功使用框架的秘诀在于改变您的应用程序以匹配框架,而不是相反.如果你不能这样做,甚至不要考虑使用框架 - 它会比你在一些好的,可靠的,文档齐全的实用程序库的帮助下从头开始编写应用程序更多的工作.

Answer 5

所以你说我们每次想要构建一个Web应用程序时都应该处理套接字和HTTP!

servlet容器本身可以被认为是一个框架,因为它处理所有这些混乱的细节,并让你编写更简单的Servlets/Filters/Listener(即:特定于您的应用程序的框架的'扩展').

所有任何框架尝试做的都是从有趣的应用程序特定代码中分离出平凡的,可重复的,容易出错的腿部代码.

但是,对于一个小型应用程序,只需使用仅使用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来提供更松散的耦合(因此更灵活)控制器,视图解析器等.

Answer 6

当面对另一个不能解决问题的框架时,我会分担你的痛苦.

经历了十年的jsp,struts,EJB,EJB2,struts2,jsf以及现在最近的所有新的Web服务framworks,xslt恐怖和wsdl-first恶梦,我绝对厌倦了.

框架存在许多问题.它们泄漏所以你必须学习更多 - 不是更少,内部框架有巨大的成本,使用外部框架成本(但更少),因为他们很少提供,然后你最终写了一些xml配置的enourmus块并花了几天纠正您最喜欢的内容帮助代码编辑器中立即看到的大小写和拼写错误.

也许答案是找到试图解决问题而不是重新定义世界的不那么浮夸的工具包,但这也很难,因为基本的应用程序模型(html over http)很尴尬 - 充其量.

再加上似乎有很多复杂因素的事实,人们似乎痴迷于将无聊的简单问题交易到复杂(但很难)的间接问题(可能是上面提到的Eric Sink的软件开发公理的变体).

加入那些了解这一切的开发人员的傲慢,并毫不犹豫地编写一个新框架来解决所有难题,只有他们不能,留下10%左右,现在只需要更难修复.

我没有.NET经验,但.NET世界似乎不那么拥挤的理论家和复杂者,也许VB的挥之不去的臭味吓跑了他们,但每当我听到有人告诉我他们已经花了1500个小时在他们的maven上config(你好？),我正在认真考虑从我的简历中删除"java".

......又是什么问题？是否有任何框架有所作为？

编辑 - 添加了Stripes和QueryDSL.

我会尝试使用带有QueryDSL + Hibernate或OpenJPA(带注释)的Stripes或GWT,只是为了实际用Java开发,并尝试限制使用wsdl-first web-services,xml-centric框架,EJB和ESB(尽可能不是啤酒).