【问题标题】:Is it possible to use a web framework but not be dependant on that framework?是否可以使用 Web 框架但不依赖于该框架?
【发布时间】:2009-04-25 19:06:59
【问题描述】:

我正在研究在我的 Java 网络应用中使用网络框架。我的基本要求是易于维护、可测试和不重复。

我已经探索过使用某种前端控制器模式和用于视图的 JSP 来编写自己的 MVC 类型的应用程序。这样做的好处是我可以完全控制我的网络应用程序的所有方面,如果我设计得当,如果我愿意的话,将来将它转移到一个经过更多测试的框架应该不难。然而,缺点是我不得不重新发明轮子。

我听说了有关当前可用 Web 框架的好消息。我一直在研究的一些技术是 Spring、Wicket、Struts、Guice、Hibernate 和 Tapestry。

我对 Tapestry 和 Wicket 有点警惕。我不太了解它们,但它们似乎偏离了 servlet->model jsp->view 公式。我不确定我是否对此感到满意。虽然,我听说 Wicket 实际上最适合 Guice 并且非常可测试。

Spring 似乎很适合,但我对试图做所有事情的框架非常警惕。我很想使用 spring-MVC,但我可以换其他组件吗?例如,我可以在使用 Spring-MVC 作为我的框架的同时使用 Guice 作为我的 DI 引擎吗?

我已经简要了解了 Struts,但它似乎对我的需求过于复杂,而且似乎是一个完整的包。

我从未使用过 Hibernate,但它似乎是 ORM 的标准,如果它类似于 ActiveRecord(我只接触过一点点),我相信它符合我的需求。

我也从未真正使用过 Guice,但人们似乎真的很喜欢它,而且我总体上是 DI 的粉丝,尽管我不确定它是如何在实际应用程序中使用的。

基本上,我只对编写 Servlet/JSP 有信心。我不反对学习替代技术,但我正在寻找关于哪些技术真正使我受益的建议。

如果我可以使用 Servlet 和 JSP 制作 MVC 应用程序,是否值得加入 Spring?还是我应该只使用 Servlets/JSP 并结合像 Guice 这样的 DI 引擎?

我很确定我想将 Hibernate 用于 ORM,但我听说它可能非常复杂。我真正在寻找的只是一种将我的 POJO 映射到数据库的方法,所以如果有更好/更容易使用的东西,我愿意查找它。

我感到迷茫,正在寻找该地区知识渊博的人的一些指导,对于任何这些问题的任何意见都将不胜感激。谢谢!

【问题讨论】:

    标签: java model-view-controller web-frameworks


    【解决方案1】:

    “Spring 似乎很适合,但我对试图做所有事情的框架非常警惕。我很想使用 spring-MVC,但我可以换入其他组件吗?例如,我可以使用 Guice作为我的 DI 引擎,同时使用 Spring-MVC 作为我的框架?”

    同意 Spring 提供了很多东西,但它是完全模块化的。您可以使用带或不带 AOP 的 DI 等等。是的,您可以将 Spring MVC 和 Guice 一起用于 DI。

    “我已经简要了解了 Struts,但它似乎过于复杂,无法满足我的需求,而且似乎是一个完整的包。”

    我使用 Struts 已经有一段时间了,但即使我开始使用它,我也发现它轻而易举。控制器一开始可能看起来势不可挡,但当你掌握它的窍门时,你会发现真正的乐趣。最好的方法是查看一些使用 Struts 的真实示例。

    “我从未使用过 Hibernate,但它似乎是 ORM 的标准,如果它类似于 ActiveRecord(我只接触过一点点),我相信它符合我的需求。”

    那么,如果您发现 Struts 很难,那么 Hibernate 是巨大的。它需要很大的学习曲线。最终会有所回报,但如果您了解 ActiveRecord,我建议您在充分了解 Hibernate 之前坚持使用它。

    “我很确定我想将 Hibernate 用于 ORM,但我听说它可能非常复杂。”

    恕我直言,非常正确……至少对于初学者而言。 (这里有人建议改变吗?)

    “如果我可以使用 Servlet 和 JSP 制作 MVC 应用程序,是否值得加入 Spring?”

    您的意思是没有 Struts 或任何其他框架?怎么样?

    似乎您正试图接受太多太快。尝试一次考虑一件事。 DI 本身在现实世界中实现起来是一件棘手的事情。哦,是的,从概念上讲它很棒,但我的意思是你需要先一一掌握。

    【讨论】:

      【解决方案2】:

      很简单,如果您对 JSP 和 Servlet 感到满意,那么如果您想省去一些 Web 编程的繁琐工作,我会考虑 Stripes 或 Struts 2。

      我对 Stripes 非常熟悉,只知道 Struts 2 类似,所以我将这篇文章重点放在 Stripes 上。

      顺便说一句,Struts 1 毫无价值。它没有任何价值(坦率地说)。

      Stripes 有几个功能,但我只关注其中的几个。

      Stripes 的主要价值,如果这是它唯一的功能,它仍然非常有价值,是它的绑定框架。

      绑定是将请求字符串值转换为操作值的过程。 Stripes 在这方面做得非常好。具体来说,Stripes 绑定在嵌套和索引参数以及类型转换方面做得很好。您可以轻松地拥有一个名为“currentDate”的表单字段,然后在您的 Action 中拥有一个“Date currentDate”,Stripes 将“做正确的事”。

      如果您有一个名为“mainMap['bob'].listOfThings[3].customer.birthDate”的表单字段,Stripes 将制作地图、创建列表、创建客户、将字符串转换为日期、填充出生日期,将客户放在列表的第 3 个位置,然后将该列表放在地图的“鲍勃”位置。 (我一直都在做这样的事情。)

      请求到动作变量的绑定真是太棒了。

      除此之外,如果您使用他们的表单标签,您会得到很好的行为,例如,当他们在您的日期字段中输入“Fred”时。您可以轻松取回表单,Fred 在字段中,并显示一条不错的错误消息。

      最后,我真的很喜欢他们的决心,因为他们的行动是他们的结果。例如,ForwardResolution 用于转发到页面,RedirectResolution 用于重定向到页面,StreamingResolution 如果您想将数据泵入套接字等。这是一个非常优雅的功能。

      Stripes 有各种各样的力量,可以做各种各样的事情,但是这 3 件是最适合我的,也是我 99% 的时间使用的。

      简单地说,它确实不碍事,轻松处理“管道”,而不会完全掩盖系统的 HTTP 请求性质。

      对于那些满足于 JSP/Servlets 的人来说,我认为 Stripes 是一个很好的进步,因为它以非常低的成本(它很容易设置)增加了良好、可靠的价值,而且不必抛弃你已经知道的一切,因为它适用于 JSP 和 JSTL。了解它用于将操作映射到 URL 的简单机制,以及将请求映射到您的操作是多么简单,您很快就会飞起来。

      也适用于 Ajax 等。

      【讨论】:

        【解决方案3】:

        这个问题说明了一些混乱。我认为最终的答案是“不,不可能使用 Web 框架但不能依赖它”。

        但你的直觉很好。您希望通过帮助正确分层和模块化代码并最大程度地减少其侵入性来最大化框架提供的一般好处。

        话虽如此,我认为 Spring 在这两个方面都是赢家。

        如果您遵循 Spring 的习惯用法,那么通过使用接口、分层和方面,您的代码结构会更好。他们对设计的一些关注势必会影响到你。这与他们提供的良好管道代码一样有用。

        您的代码库不必是 100% Spring。我已经看到 Spring 用于增强未从头到尾重写的遗留 Java 应用程序。

        Struts 往往不是一个好的选择,因为它只是一个 Web 框架。它鼓励您将所有处理放在 Action 子类中,永远不要出来。 Spring 注入了将 Web 层与后端分离的服务接口的想法。更换 Web 层并将服务公开为 SOAP、RMI、EJB 或远程 HTTP 调用更容易。

        Hibernate 比 Struts 复杂得多。如果选择 Spring,请使用持久化接口并从 Spring JDBC 开始。当您准备好使用 Hibernate 时,您总是可以编写一个新的实现并将其简单地注入到您的 JDBC 版本曾经所在的位置。

        【讨论】:

          猜你喜欢
          • 2012-03-14
          • 1970-01-01
          • 1970-01-01
          • 2015-05-21
          • 2016-07-12
          • 2011-02-27
          • 1970-01-01
          • 2015-09-28
          • 1970-01-01
          相关资源
          最近更新 更多