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

我太累了,不得不每隔一天学习另一个Java Web框架。
JSP,Struts,Wicket,JSF,JBoss Seam,Spring MVC等等,这些无数的框架都试图解决相同的问题。 但是,他们中没有一个真正解决了根本问题 – 这就是为什么一直都会有越来越多的新问题出现。

大多数人对第一印象看起来非常明亮和shiny,因为他们简化了简单的事情。
但是一旦实现了真实世界的用例,就会遇到问题。
通常,框架不提供任何帮助,而是根据框架本身的逻辑和环境来阻碍和限制select。

总之,使用框架时我看到以下缺点:

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

在我看来,爱因斯坦以下的引用很适合这里:

“我们不能用创造它们时使用的同样的思维来解决问题。”

回到我过去很好的PHP编程时代,编码仍然很有趣,也很有成效,我曾经为大多数事情编写自己的框架,只是从一个项目复制粘贴到下一个项目。
这种方法付出了很多,导致了快速开发,没有任何开销和框架,实际上比大多数Java框架,但只有几百行代码在单个文件加上一些简单的mod_rewrite规则。
这当然不是解决networking开发的所有问题,但是简单,快速和直截了当。
在完全适应当前项目的要求的同时,它也很容易扩展,并且由于零开销而具有非常高的性能。

那么为什么所有这些使用这个框架的麻烦,为什么不把它们全部扔掉,并回到根源呢?
当我们明天开始下一个新的框架项目时,我应该对老板说些什么?
还是有可能真的有所作为的框架?
还是我忽略了一些隐藏的优势?

回到我过去很好的PHP编程时代,编码仍然很有趣,也很有成效,我曾经为大多数事情编写自己的框架,只是从一个项目复制粘贴到下一个项目。 这种方法付出了很多,导致了快速的开发,没有任何开销和一个框架,实际上比大多数Java框架更强大

原谅我相信那不是一秒钟。

但在一个文件中只有几百行代码加上一些简单的mod_rewrite规则。 这当然不是解决networking开发的所有问题,但是简单,快速和直截了当。

所以,基本上你在几个月或几年的时间内开发了自己的框架,根据自己的需要量身定制,并且可以很快地工作,因为你知道这个框架。

然而你不明白为什么其他人也这样做,然后试图把结果转化为每个人都可用的东西?

你开发这个伟大的框架在哪里? 如果function强大且易于使用,那么专用社区在哪里,数以千计的用户和数百个网站是如何发展起来的呢?

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

那么,那就是你的问题。 为什么要在每个项目之后抛弃每个框架获得的专业知识?

这个想法是select一个框架,并坚持在多个项目,让你精通它。 你必须投入一些时间来学习框架,然后通过让你在更高层次上工作来节省时间。

提出自己的框架的问题是,你会犯的所有已经build立的框架已经绊倒和解决的所有相同的错误。 这在安全方面尤其如此。

只要问杰夫和那些家伙在执行堆栈溢出WMD时必须考虑的事情。 我宁愿使用他们在项目中生成的东西,而不是从头开始实施。 这只是一个例子。

这个问题当然不仅仅是Java框架。 我已经失去了我所看到的C ++ MFC项目的数量,这些项目试图让他们的需求陷入文档/视图模型(这实际上只是文本和graphics编辑器的工作 – 数据库应用程序特别难于处理) 。

成功的框架使用的秘密是改变你的应用程序来匹配框架,而不是相反。 如果你不能这么做的话,甚至不要去考虑使用这个框架 – 最终的工作要比在一些好的,可靠的,有文档logging的工具库的帮助下从头开始编写应用程序的工作要多得多。

这里是来自线程的 Kev引用你最有争议的编程意见是什么? 这在这里非常适合:

我认为整个“企业”框架的事情是烟雾缭绕。 J2EE,.NET,大多数Apache框架和大多数抽象来pipe理这样的事情,创造出比他们解决的复杂得多的事情。

采取任何常规的Java或.NET OMR,或者任何一种所谓的现代MVC框架,来解决单调乏味,简单的任务。 最终你会写出大量很难validation和写入的难看的XML样板文件。 你有大量的API,其中一半是集成其他API的工作,不可能回收的接口,以及只需要克服Java和C#的灵活性的抽象类。 我们根本不需要那么多。

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

这一点不是复杂性==不好,这是不必要的复杂==不好。 我曾经在大规模的企业安装中工作过,其中有一些是必要的,但是即使在大多数情况下,一些本地的脚本和一个简单的Web前端也是解决大多数用例所需要的。

我试图用简单的Web框架,开放源代码数据库和简单的编程结构来replace所有这些企业级应用程序。

那么你是否说我们应该在每一次我们想build立一个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来提供更松散的耦合(因此更灵活)的控制器,视图parsing器等。

当面对另一个没有办法的框架时,我分享你的痛苦。

在经历了十年的jsp,struts,EJB,EJB2,struts2,jsf以及现在最近所有新的Web服务框架,xslt恐怖和wsdl-first-nightmares之后,我绝对厌烦了。

框架有许多问题。 他们泄漏,所以你必须学习更多 – 不要less,内部框架有巨大的成本,使用外部框架成本太less(但less得多),因为他们很less交付,然后你最终编写XMLconfigurationenumemus块和花费天校正在您最喜欢的内容帮助代码编辑器中,您立即看到了大小写和拼写错误。

也许答案就是find那些试图解决问题但不重新定义世界的,不那么浮夸的工具包 ,但是基本的应用模型(html over http)很尴尬 – 这也是很难的。

再加上一个事实,那就是似乎有很多复杂的东西,那些似乎沉迷于无聊的简单问题的复杂(但是很难)的问题(也许是上面提到的Eric Sink的软件开发公理的变体)。

加上知道这一切的开发人员的傲慢,不要犹豫,写一个新的框架来解决所有困难的问题,只有他们不能,剩下10%,现在只是更难修复。

我没有.NET的经验,但.NET世界似乎没有理论家和复杂的人拥挤,也许VB的挥之不去的痕迹吓倒了他们,但每次我听到有人告诉我,他们花了1500 小时在他们的Mavenconfiguration(你好?),我正在认真考虑从我的简历中删除“java”。

…又是什么问题? 有什么框架有所作为吗?

编辑 – 添加Stripes和QueryDSL。

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

那么,是不是每天都做同样的无聊…?

我曾经不得不在一个试图在JSF中实现它的项目上工作。 这是一场噩梦。

大部分的工作时间都花在了编译工作上。 不less于一半的编译不起作用的事实是另一回事。 几乎没有教程。 文档基本上是一个自动化的源代码导出,没有人的意见。 怎么能期望这样工作?

在我们看到的几个框架中,只有Sun能够创build一个可编译的新项目! 另一个只能产生一堆东西,花了很多天才能打到可编译的状态。

networking几乎没有声音。 对于任何search,我们不超过20页的search结果,有用的前1-3。 在那些相关的事情中,有一半的人在呼救,另一半则宣布他们呼救,没有人来,他们失去了时间和兴趣,放弃了这项技术。

所以我们花了很多时间,只做了一些简单的事情,例如几个星期就可以用ASP.NET来完成。

然后我们研究了其他的JSF框架。 令我们惊讶的是,我们发现它们都非常不相容。

一点也不奇怪,我们也join了JSF下降的行列。

考虑一下相反的观点。 我现在在一家商店工作,不使用JSP标准以外的任何框架。 每个人都有不同的做事方式,我们对分离和安全问题(如validation)这样的概念非常宽松。

虽然我不认为框架的使用会自动使你成为一个更好的编码器,但我确实认为,通过使用大多数框架实现的标准devise模式,并且通过轻松访问效用函数(如validation),我认为你有可能成为被迫编码达到一定标准。

在Web应用程序devise中,您并不是每次都发明轮子,所以您最终会将自己的解决scheme转换为常规任务,或者使用框架。 我假设,通过使用一个常用的框架而不是自己的,你将得到经过良好testing和灵活的底层代码。

将自己的解决scheme作为学术追求没有什么问题,但是我认为有些人把更多的时间投入到一个可靠的解决scheme中,然后我可以花费。 以log4j为例,很容易滚动你的logging器,但是log4j经过了很好的testing和维护,他们花了很多时间来提高灵活性和性能,使得你自己的logging器无法触及的程度。 最终的结果是一个健壮的框架,但也足够简单,甚至在最基本的应用程序中使用。

对我来说有效的是:你不应该学习任何你听到的Web框架,看看它,看看它是否让你编写代码舒服,询问各种计算器或论坛,看看它的优点和缺点,然后学习和学习它很好,只是坚持下去,直到你觉得它的破碎或过时。 你写的任何一个网页框架本身都是很好的,如果你真的知道它的作用,那么这个网站框架就是一个有趣的工作。 如果你不这样做,你只是在没有指南针的沙漠中游荡! 我也发现21天的书是一个肯定的方式,你不掌握框架或技术。 Docs在采用af / w的时候肯定是要考虑的事情,如果你自己查看代码,这也是有帮助的(实际上,当我面对一些我觉得很奇怪的行为时,这是最好的帮助。

1 – 为什么所有这些使用这个框架的麻烦,为什么不把它们全部扔掉,并回到根源呢?

如果你回到根源你重写代码,一次又一次做相同的事情+大多数这些f / ws是开放源代码意味着他们可能更好的维护比你独自一人对自己的f / w。

2 – 当我们明天开始下一个新框架的项目时,我应该对老板说些什么?

这是我第一次使用这个f / w工作,我不明白为什么我们应该使用这个f / w我已经知道X,我真的很擅长它。 考虑到我学习这个f / w的成本,由于我对这种af / w的无知而必须完成的返工成本。 我认为我们最好使用X,如果这是一个特定的要求,我们应该争取,只有当我们真的必须陈述以前的笔记。

还是有可能真的有所作为的框架?

只有那些解决你的思维方式而不是你写代码的方式的人(认为struts在执行MVC模式的黄金时代)。

还是我忽略了一些隐藏的优势?

想不到任何tbh。

在PHP中你有同样的问题:有更多的框架比你有指望,每个都是最好的和最好的(尽pipe你有一些提示:纯PHP5devise与PHP4兼容性,Rails理念(不灵活的文件夹层次结构,自动生成代码)与库的方法…),你花更多的时间search和探索的可能性比编写你的代码!
但在PHP中,它允许预先解决常见问题,如I18N支持,插件集成,会话pipe理和身份validation,数据库抽象,模板,Ajax支持等。避免重新发明每个项目的轮子,在新手共同陷阱。

当然,Java框架也有一些提示:大或小? 有据可查的文件吗? 广泛使用还是保密? 对于XML迷还是不行? 等等。
我认为大多数框架都是针对大型项目,学习时间不是一个大问题,可扩展性和易用性很重要,等等。对于小型项目来说,这可能是过度的。

在这样的框架中也有一个趋势,就是要制定一套松散耦合的图书馆,而不是一个单一的框架。 在PHP世界里,Zend框架就是这样(有些人甚至否认“框架”这个词的用法…)。
所以解决了“解决常见问题”而不妨碍的问题。

所以你认为如果我们都在每个项目中发明轮子会更好?

你可能会看到过多的框架成为一个问题,而且这使得select你自己的框架变得更加困难。 但另一方面,你不必尝试每一个; 即使你这样做,你最终也会喜欢其中的一些。 您将拥有一个最喜欢的ORM框架,另一个用于Web开发,IoC等。

它有助于阅读一些论坛,以了解哪些是最受欢迎的; 他们一定是受欢迎的一个原因,即使它不是正确的理由(如技术上优越,也许是因为stream行语超负荷或任何其他pipe理人员stream行),知识框架将是有益的,因为你将能够参与使用它的几个项目。

另外,使用框架,而不是写自己的将会为您节省很多的问题。 错误并不总是被作者发现和解决; 这通常由框架的用户完成。 你说你最终在PHP中拥有自己的私有框架; 我敢打赌,这不是没有错误,但也许你不知道,因为你是唯一的用户和唯一的编码器。

不过,我对你提到的一些观点持不同意见,但我同意你这些无聊的工作。

是的所有Web应用程序都是关于显示表单,收集数据,validation,发送数据以便存储在数据库中的页面,以及通过search表单过滤存储的数据,并在表格中显示结果并select一个或多个logging进行操作(CRUD,或所有关于改变数据库状态的商业行为)。

但是我只工作了四年,当然还有我四年的学术研究。 我觉得这种发展是无聊的,因为你没有发明algorithm,当你发现新的框架时,你会很高兴,如果你将一个AI引擎集成到你的应用程序中会更快乐,但最终我觉得这个工作是虚构的作品,还是让机器工作,所以我们为什么不自动化所有这些东西。

是另一个框架;)MDA模型驱动架构,简单地说就是从PIM(平台无关模型)转换到PSM(平台特定模型),例如从UML到代码。

这可能会解决您的学习曲线和技术变化的问题,因为您只需要善于build模,因为有一些框架实现了MDA规范,如AndroMDA,因为它具有采用类图,用例,顺序图表和活动图表,并生成数据库创build脚本,POJO,Hibernate映射,Spring / EJB,JSF / Struts,.NET代码。

当然,这样的框架不会产生100%的代码,但会产生很大的百分比,当然你会问这个框架将会解决复杂而棘手的需求情况吗? 今天我会说不,明天是的。

那么为什么你我不投资这个伟大的框架的发展。