当前位置：文江博客话题详情

web-applications Java web-frameworks

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

发布于 2024-07-17 09:26:35 字数 1435 浏览 5 评论 0 原文

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

大多数第一印象确实看起来非常明亮和闪亮，因为它们简化了简单的事情。
但一旦涉及到现实世界用例的实现，就会遇到问题。
通常，框架不提供任何帮助，而是通过强制根据框架自身的逻辑和环境来实现来阻碍并限制选择。

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

主要是一个陡峭的学习曲线，你首先需要理解有时相当学术的概念，并知道一堆配置文件的含义和位置，然后才能开始。
文档通常或多或少都很糟糕，要么缺少公共可访问的在线参考，要么过时，要么混淆不同的不兼容版本，要么将所有这些混在一起，并且通常不提供任何有用的示例。
该框架由无数的类组成，这使得仅通过浏览源代码实际上不可能了解其预期用途。
因此，你需要购买一些“XYZ in action for dummies in 21 days”之类的书籍，这些书籍的用户界面很差，因为它们缺少全文搜索，而且携带起来很重。
要真正使用这个框架之一，您需要通过记住足够的类和方法名称来熟记如何按照框架要求的方式完成事情，直到您的大脑充满愚蠢且无用的信息，您无法用于其他任何事情。
开销很大，会降低应用程序的性能，并使您的大脑在尝试了解到底发生了什么时感到麻木。
在现实世界中，由于生产力的压力，通常没有时间熟悉新事物。由于这种边做边学的方法，人们总是只寻找完成下一个任务的最快方法，而不是真正理解新工具及其可能性。
在我看来，遵循标准可以让项目新手快速上手的论点是站不住脚的，因为即使在同一家公司内，每个项目都使用不同的框架（至少在我看来）。

在我看来，阿尔伯特·爱因斯坦的以下引言非常适合这里：

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

回到我过去的 PHP 编码时代，那时编码仍然很有趣且富有成效，我曾经为大多数事情编写自己的框架，然后将它们从一个项目复制粘贴到下一个项目。
这种方法的效果非常好，开发速度很快，完全没有任何开销，而且框架实际上比大多数 Java 框架更强大，但单个文件中只有几百行代码，加上一些简单的 mod_rewrite 规则。
这当然并不能解决 Web 开发的所有问题，但它简单、快速且开门见山。
在完美适应当前项目的要求的同时，它还易于扩展，并且由于零开销而具有非常高的性能。

那么，为什么使用这个框架会带来这么多麻烦，为什么不把它们全部扔掉并回到根源呢？
当我们明天再次使用新框架开始下一个项目时，我应该对我的老板说什么？
或者是否有真正有所作为的框架？
还是我忽略了一些隐藏的优势？

原文

I'm so tired of having to learn yet another Java web framework every other day.
JSP, Struts, Wicket, JSF, JBoss Seam, Spring MVC to name just a few - all this countless frameworks out there try to address the same issues. However, none of them really solves the fundamental problems - that's why there are still coming up more and more new ones all the time.

Most do look very bright and shiny on the first impression because they simplify doing simple things.
But as soon as it comes to the implementation of a real world use case one is running into problems.
Often the frameworks don't provide any help but are hindering one and limiting the options by forcing things to be implemented according to the frameworks own logic and environment.

In short, I see the following disadvantages when using a framework:

There mostly is a steep learning curve and you first need to understand sometimes quite academic concepts and know meaning and location of a bunch of configuration files before you can get started.
The documentation usually is more or less awful, either missing a public accessible online reference, is helpless outdated, confuses different incompatible versions or all of this together and often doesn't provide any helpful examples.
The framework consist of zillions of classes which makes it practically impossible to understand the intended use only by browsing the sources.
Therefore you need to buy some "XYZ in action for dummies in 21 days" kind of books which have a bad user interface because they are missing a full text search and are heavy to carry around.
To really use one of this frameworks you need to learn by heart how things can be done the way the framework requires it by remembering the adequate classes and method names until your head is full of stupid and useless information you can't use for anything else.
There is a big overhead, slowing down your applications performance and making your brain feeling numb when try to understand what really is going on.
In the real world there is usually no time to get well familiar with something new because of the pressure of being productive. As a consequence of this learning by doing approach one always looks only for the fastest way to get the next task done rather than really understanding the new tool and it's possibilities.
The argument that following a standard would allow people who are new to a project to quickly get started is not valid in my view because every project uses a different framework even within the same company (at least in my case).

It seems to me that the following quote from Albert Einstein fits here very well:

“We can't solve problems by using the same kind of thinking we used when we created them.”

Back in my good old PHP coding days when coding still was fun and productive, I used to write my own frameworks for most things and just copy-pasted and adopted them from one project to the next.
This approach paid out very well, resulting in fast development, no overhead at all and a framework which actually was mightier than most Java frameworks out there but with only a few hundred lines of code in a single file plus some simple mod_rewrite rules.
This certainly wasn't solving all problems of web development, but it was simple, fast and straight to the point.
While perfectly adjusted to the requirements of the current project, it also was easy expandable and had a very high performance due to zero overhead.

So why all that hassle with using this frameworks, why not throwing them all away and going back to the roots?
What should I say to my boss when we're starting tomorrow the next project with a new framework again?
Or are there maybe frameworks which really make a difference?
Or some hidden advantages I have ignored?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

冬天旳寂寞 2024-07-24 09:26:35

回到我过去的 PHP 编码时光
当编码仍然很有趣并且
富有成效，我曾经自己写过
大多数事情的框架，只是
复制粘贴并采用它们
项目到下一个。这种方法
支付得很好，结果很快
开发，完全没有任何开销，并且
实际上更强大的框架
比大多数 Java 框架都要好

请原谅我一秒钟都不相信这一点。

但只有几百行
单个文件中的代码加上一些简单的
mod_rewrite 规则。这当然
并没有解决网络的所有问题
开发，但简单、快速
并开门见山。

因此，基本上，您在数月或数年的时间内开发了自己的框架，根据自己的需求量身定制，并且可以非常快速地使用它，因为您非常了解它。

但你却无法理解为什么其他人也这样做，然后试图将结果变成每个人都可以使用的东西？

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

每个项目都使用不同的
即使在同一家公司内也有框架
（至少就我而言）

好吧，这就是你的问题。为什么在每个项目之后你会放弃从每个框架中获得的专业知识？

我们的想法是选择一个框架并在多个项目中坚持使用它，以便您精通它。你必须投入一些时间来学习框架，然后它可以让你在更高的水平上工作，从而节省你的时间。

回复收藏 0 原文

意中人 2024-07-24 09:26:35

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

只要问问 Jeff 和其他人，他们在堆栈溢出中实现 WMD 时必须考虑什么。我宁愿使用他们在项目中生成的内容，而不是从头开始实现它。这只是一个例子。

回复收藏 0 原文

诠释孤独 2024-07-24 09:26:35

以下是来自线程 Kev 的引用Whats-your-most-controversial-programming-opinion/">你最有争议的编程观点是什么？这非常适合这里：

我认为整个“企业”框架都是雾里看花。 J2EE、.NET、大多数 Apache 框架和管理此类事物的大多数抽象所产生的复杂性远远超过它们所解决的问题。

采用任何常规的 Java 或 .NET OMR，或者任何所谓的现代 MVC 框架，它们都能“神奇”地解决繁琐、简单的任务。您最终会编写大量难看的 XML 样板，这些样板很难验证和快速编写。您拥有大量的 API，其中一半只是为了集成其他 API 的工作、无法回收的接口以及仅用于克服 Java 和 C# 的不灵活性所需的抽象类。我们根本不需要其中的大部分。

所有不同的应用程序服务器都有自己该死的描述符语法、过于复杂的数据库和组件产品怎么样？

问题的关键不是复杂性==不好，而是不必要的复杂性==不好。我曾在大型企业安装中工作过，其中一些是必要的，但即使在大多数情况下，一些自制脚本和一个简单的 Web 前端就足以解决大多数用例。

我会尝试用简单的 Web 框架、开源数据库和简单的编程结构来替换所有这些企业应用程序。

回复收藏 0 原文

大姐，你呐 2024-07-24 09:26:35

问题当然不仅仅是 Java 框架。我已经记不清有多少个 C++ MFC 项目在尝试将其需求硬塞到文档/视图模型中（这实际上只适用于文本和图形编辑器 - 数据库应用程序特别难以硬塞）。

成功使用框架的秘诀是更改您的应用程序以匹配框架，而不是相反。如果您做不到这一点，甚至不要考虑使用该框架 - 与您在一些优秀、可靠且文档齐全的实用程序库的帮助下从头开始编写应用程序相比，这最终会增加更多的工作量。

回复收藏 0 原文

烧了回忆取暖 2024-07-24 09:26:35

那么您是说我们每次想要构建 Web 应用程序时都应该处理套接字和 HTTP！

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

任何框架试图做的就是将平凡的、可重复的、容易出错的跑腿代码与有趣的特定于应用程序的代码分开。

但是，对于小型应用程序，您只需使用 Model 2 MVC 就可以摆脱困境方法仅使用 JSP 和 Servlet。

示例：

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 来提供控制器、视图解析器等的更松散的耦合（因此更灵活）。

So are you saying we should deal in sockets and HTTP every time we want to build a web application!

The servlet container itself can be considered a framework, since it handles all these messy details, and leaves you to write much simpler Servlets/Filters/Listeners (ie: 'extensions' of the framework specific to your application).

All any framework tries to do is separate mundane, repeatable, error-prone, legwork code from the fun application-specific code.

However, for a small application, you can get away with simply having a Model 2 MVC approach which uses only JSPs and Servlets.

Example:

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);
    }
}

Then as your app becomes more sophisticated, you could look at using Spring MVC to provide looser coupling (and hence more flexible) of controllers, view resolvers etc..

回复收藏 0 原文

陌伤浅笑 2024-07-24 09:26:35

当遇到另一个无法解决问题的框架时，我和你一样痛苦。

在经历了十年的 jsp、struts、EJB、EJB2、struts2、jsf 以及最近所有新的 Web 服务框架、xslt 恐怖和 wsdl 优先的噩梦之后，我绝对受够了。

框架存在许多问题。它们泄漏，所以你必须了解更多 - 同样，内部框架成本高昂，使用外部框架的成本也很高（但要少得多），因为它们很少提供，然后您最终会编写大量的 xml 配置块，并花费数天时间纠正您在最喜欢的内容帮助代码编辑器中立即看到的大小写和拼写错误。

也许答案是找到不那么浮夸的工具包，试图解决问题但不重新定义世界，但这也很困难，因为基本应用程序模型（http 上的 html）充其量是笨拙的。

添加一个事实，似乎有很多复杂器周围的人们似乎痴迷于将无聊的简单问题转换为复杂（但困难）有趣的问题（可能是上面提到的埃里克·辛克（Eric Sink）的软件开发公理的变体。）

再加上了解一切并且毫不犹豫地开发人员的狂妄自大写一个新的框架来为你解决所有的难题，只是他们不能，还剩下10%，只是现在更难解决。

我没有 .NET 经验，但 .NET 世界似乎不那么拥挤的理论家和复杂化者，也许 VB 挥之不去的臭味吓跑了他们，但每次我听到有人告诉我他们已经花了 1500 个小时在他们的 Maven 配置上（你好？），我正在认真考虑从我的简历中删除“java”。

……又问了什么问题？是否有任何框架可以发挥作用？

编辑 - 添加了 Stripes 和 QueryDSL。

我会尝试使用 Stripes 或 GWT 与 QueryDSL + Hibernate 或 OpenJPA（带注释），只是因为您实际上是用 Java 开发的，并尝试限制使用 wsdl-first Web 服务、以 xml 为中心的框架、EJB 和 ESB（不是啤酒）尽可能多。

I share your pain when confronted with yet another framework that doesn't do the trick.

Having survived ten years of jsp, struts, EJB, EJB2, struts2, jsf and now more recently all the new web services framworks, the xslt horrors and wsdl-first nightmares, I am definitely fed up.

There is a number of problems with frameworks. They leak so you have to learn more -not less, inhouse frameworks have huge costs, using external frameworks costs too (but much less), as they seldom deliver, and then you end up writing enourmus chunks of xml-configuration and spend days correcting case and spelling errors that you had seen immediately in your favorite content helping code editor.

Maybe the answer is to find less pompous toolkits that tries to solve a problem but not redefine the world, but that is hard too as the fundamental application model (html over http) is awkward - at best.

Add the fact that there seems to be a lot of complicators around, people that seems to be obsessed of trading boring simple problems to complex (but hard) interresting problems ( maybe a variant of Eric Sink’s Axiom of Software Development mentioned above.)

Add the hubris of developers that knows it all and do not hesitate to write a new framework to solve all the hard problems for you, Only that they can't, leaving 10% left, only much harder to fix now.

I have no .NET experience, but the .NET world seems to be less crowded with theorists and complicators, and maybe the lingering stink of VB is scaring them off, but everytime I hear someone telling me that they have spent 1500 hours on their maven config (hello?), I am seriously considering deleting "java" from my resume.

...what was the question again? Are there any frameworks that make a difference?

EDIT - added Stripes and QueryDSL.

I would try Stripes or GWT with QueryDSL + Hibernate or OpenJPA (with annotations) just for the fact that you actually develop in Java, and try to limit the use of wsdl-first web-services, xml-centric frameworks, EJB and ESBs (not the beer) as much as possible.

回复收藏 0 原文

灰色世界里的红玫瑰 2024-07-24 09:26:35

我曾经参与过一个项目，试图在 JSF 中实现它。这是一场噩梦。

大部分工作时间都花在了编译上。事实上，至少有一半的编译内容不起作用，这是另一回事。几乎没有教程。文档基本上是自动源代码导出，没有人工注释。怎么能指望一个人能像这样工作呢？

在我们见过的几个框架中，只有 Sun 能够创建一个完全可编译的新项目！另一个只能产生一堆东西，需要很多天才能达到可编译状态。

网络上几乎一片寂静。对于任何搜索，我们的搜索结果不超过 20 页，前 1-3 页是有用的。在相关的发现中，一半的人在呼救，另一半则宣称他们呼救了，但没有人来，他们失去了时间和兴趣并放弃了这项技术。

因此，我们花了很多时间，只做了一些简单的事情，例如使用 ASP.NET 可以在几周内完成的事情。

然后我们研究了替代的 JSF 框架。令我们惊讶的是，我们发现它们完全不兼容。

毫不奇怪，我们也加入了放弃 JSF 的行列。

回复收藏 0 原文

三五鸿雁 2024-07-24 09:26:35

考虑一下反面观点。我现在在一家不使用任何超出 JSP 标准的框架的商店工作。每个人都有不同的做事方式，我们对解耦等概念和验证等安全问题非常宽松。

虽然我不认为使用框架会自动让你成为更好的编码员，但我确实认为通过使用大多数框架实现的标准设计模式并轻松访问验证等实用功能，我认为你有可能成为被迫编码达到一定标准。

在 Web 应用程序设计中，您并不是每次都发明轮子，因此您最终要么为常见任务推出自己的解决方案，要么使用框架。我假设通过使用常用框架您将获得经过充分测试且灵活的底层代码，而不是自行开发。

将自己的解决方案作为学术追求并没有什么错，但我承认有人在一个强大的解决方案上投入了比我可能花的更多的时间。以 log4j 为例，非常容易滚动您的记录器，但是 log4j 经过了良好的测试和维护，并且他们花时间将灵活性和性能提高到大多数滚动您自己的记录器无法触及的程度。最终结果是一个强大但也足够简单的框架，甚至可以在最基本的应用程序中使用。

回复收藏 0 原文

指尖上得阳光 2024-07-24 09:26:35

对我有用的是：你不应该只是学习你听说过的任何 Web 框架，看看它，看看它是否能让你舒适地编码，在 stackoverflow 或论坛上询问，看看它的优点和缺点，然后学习它并学习它很好，坚持下去，直到你觉得它坏了或完全过时了。您所写的任何网络框架本身都很好，并且如果您“真正”知道它的作用，那么使用它会很有趣。如果你不这样做，你就只是在没有指南针的沙漠中徘徊！我还发现 21 天的书是让你不掌握框架或技术的可靠方法。在采用 af/w 时，文档肯定是需要考虑的事情，如果您自己查看代码，它也会有所帮助（实际上，当我遇到一些我觉得很奇怪的行为时，这是对我最好的帮助。1-

所以为什么使用时会遇到那么多麻烦这个框架，为什么不把它们全部扔掉并回到根源呢？

如果你回到根源，你会一遍又一遍地重写代码，做同样的事情+大多数 f/ws 都是开源的意味着它们可能会更好？

新框架开始下一个项目时，我应该对我的老板说什么

2-当我们明天再次使用不明白为什么我们应该使用这个f/w，我已经知道X并且我真的很擅长它，记住我学习这个f/w的成本，由于我的无知而必须完成的返工成本。我认为我们最好使用 X，如果这是一个特定的要求，我们应该争取它，并且只有在我们确实必须说明前面的注释时才这样做。

或者是否有真正发挥作用的框架？

只有那些解决您的思考方式而不是您编写代码的方式的人（想想 struts 在其黄金时代强制执行 MVC 模式）。

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

想不出任何TBH。

回复收藏 0 原文

枕头说它不想醒 2024-07-24 09:26:35

你在 PHP 中也有同样的问题：框架多得数不过来，每一个都是最好的和最伟大的（尽管你有一些提示：纯 PHP5 设计与 PHP4 兼容性、Rails 哲学（不灵活的文件夹层次结构、自动生成的）代码）与库方法...），并且您花费更多时间搜索和探索可能性而不是编写代码！
但在 PHP 中，它允许预先解决常见问题，例如 I18N 支持、插件集成、会话和身份验证管理、数据库抽象、模板、Ajax 支持等。避免在每个项目上重新发明轮子，并陷入困境。新手常见的陷阱。

当然，Java 框架也有一些提示：大还是小？有据可查吗？广泛使用还是保密？是否适合 XML 爱好者？等等
我想大多数框架都是针对大型项目的，在这些项目中，学习时间不是大问题，可扩展性和易于部署很重要，等等。对于小型项目来说，它们可能有点过分了。

此类框架还有一种趋势，旨在构建一组一致的松散耦合库，而不是单一框架。在 PHP 世界中，Zend 框架就是这种情况（有些人甚至否认使用“框架”一词......）。
所以它解决了“解决常见问题”的问题，而不妨碍。