我不是 Java 开发人员,所以我可能会弄错一些术语……但是。
我集成的一个应用程序正在从 Spring 迁移到 Wicket。虽然它不应该影响我与它的整合,但我想知道他们为什么要这样做?
据我所知,Spring 是更流行的框架。我对它一无所知,除了它很受欢迎。我确实阅读了 Wicket 页面,Wicket 看起来非常简单明了。
Wicket 有哪些优势?
在我看来,改变你的整个框架将是一些工作,所以我想知道 Wicket 是否提供了 Spring 不提供的东西?
我不是 Java 开发人员,所以我可能会弄错一些术语……但是。
我集成的一个应用程序正在从 Spring 迁移到 Wicket。虽然它不应该影响我与它的整合,但我想知道他们为什么要这样做?
据我所知,Spring 是更流行的框架。我对它一无所知,除了它很受欢迎。我确实阅读了 Wicket 页面,Wicket 看起来非常简单明了。
Wicket 有哪些优势?
在我看来,改变你的整个框架将是一些工作,所以我想知道 Wicket 是否提供了 Spring 不提供的东西?
我经常在圈子里吹捧的优点是:
以下是 apache wicket 的一些功能:
POJO 组件模型
Wicket 中的页面和组件是支持封装、继承和事件的真实 Java 对象。
易于开发
因为 Wicket 是 Java 和 HTML,所以您可以利用您对 Java 的了解或您最喜欢的 HTML 编辑器来编写 Wicket 应用程序。
关注点分离
Wicket 不会将标记与 Java 代码混合,也不会向标记文件添加特殊语法。HTML 和 Java 的世界是平行的,并且仅通过 Wicket id 相关联,Wicket id 是 HTML 中的属性和 Java 中的组件属性。由于 Wicket HTML 只是 HTML,而 Wicket Java 只是 Java,因此编码人员和设计人员可以在很大程度上独立工作,而无需依赖任何特殊工具。
安全的
Wicket 默认是安全的。URL 不会暴露敏感信息,并且所有组件路径都是会话相关的。必须采取明确的步骤在会话之间共享信息。此外,URL 加密允许高度安全的网站。
透明、可扩展的集群支持
所有 Wicket 应用程序都将自动在集群上运行,无需额外工作。一旦了解了瓶颈,Wicket 就可以调整页面状态复制。下一版本的 Wicket 将支持客户端模型以实现零状态可扩展性。
透明后退按钮支持
Wicket 支持可配置的页面版本管理。当用户提交表单或从他们使用浏览器中的后退按钮访问的页面点击链接时,Wicket 能够将页面对象恢复到页面最初呈现时的状态。这意味着您可以编写支持后退按钮的 Web 应用程序,而且工作量很少。
多标签和多窗口支持
Wicket 提供了一种编写支持多窗口和多选项卡使用的应用程序的简单方法,允许开发人员在用户打开新的浏览器窗口或选项卡时做出正确反应
可重用组件
Wicket 中的可重用组件特别容易创建。您不仅可以使用 Java extends 关键字扩展现有组件,还可以创建将一组组件关联为可重用单元的面板组件。
简单、灵活、可本地化的表单验证
在 Wicket 中编写和使用验证器很简单。自定义和本地化验证错误消息的显示和内容也很容易。
类型安全会话
Wicket 消除了手动管理 HttpSession 属性的需要。页面和组件对象透明地存储在会话中,您的应用程序也可以创建具有类型安全属性的自定义会话子类。会话中存储的所有对象都可以自动参与集群复制。
工厂可定制
Wicket 是非常可扩展的。大多数操作都可以通过工厂或工厂方法进行定制。
可拆卸模型
Wicket 中的模型对象在集群中的内存和网络使用方面非常轻量级。使用模型时,它可以“附加”,用来自持久存储的信息填充自己。当模型不再使用时,可以重置瞬态信息,减小对象的大小。
边框组件
Wicket Border 组件能够以可重用的方式装饰页面。这对于继承常见的导航结构或布局特别有用。
支持所有基本 HTML 功能
Wicket 支持图像标签、链接、表单以及您在 Web 应用程序开发中习惯使用的所有其他内容。
属性的程序化操作
Wicket 组件可以以编程方式更改任何 HTML 标记属性。
自动转换
表单验证后,可以使用 Wicket 转换器更新模型。大多数普通转换都是内置的,很容易编写新的转换器。
动态图像
Wicket 使图像的使用、共享和生成变得非常容易。可以通过简单地实现绘画方法来创建动态图像。
可分页列表视图
Wicket 中的 ListView 非常强大。您可以在 ListView 行中嵌套任何类型的组件,甚至是其他 ListView。PageableListView 支持大型列表的导航链接。
树组件
开箱即用的树组件,用于导航和选择节点。
本土化
HTML 页面、图像和资源字符串都可以本地化。
Spring 不仅仅是 Spring MVC。您可以(并且可能应该)将 Spring与Wicket 一起使用。
检票口岩石!
Spring(其中的 UI 部分称为 Spring MVC)似乎是一个巨大的,“做所有事情,包括厨房水槽”,当我开始评估 Spring(和 Spring MVC)。在我看来,今天 Spring 似乎并不专注于任何一件事。最初我认为它只是一个依赖注入框架,但它很快发展为试图成为所有人的一切,并且失去了简单性。
我在 Spring 上阅读的书籍中有包含太多 XML 配置的示例。XML 配置文件中的错误比 java 代码中的错误更难调试和修复,您可以使用调试器单步执行。
无论如何用 Java 代码而不是 XML 声明东西有什么问题?从什么时候开始有人下令无论如何都应该在 XML 中声明所有内容?如果您喜欢在复杂的 XML 配置文件的海洋中畅游,那么请选择 Spring。如果您喜欢完成工作并提高工作效率,请选择 Wicket。
Wicket 非常专注于成为最好的基于 Java 的 Web 应用程序开发 UI 框架。它不会试图将您锁定在任何特定的依赖注入框架或任何特定的持久性框架中(与 JDO/JPA、DataNucleus、Hibernate 等一起使用)。
它的重点显然是 UI,但您可以使用任何您喜欢的依赖注入框架(您不必使用 Spring 的 DI,但如果您愿意,可以使用)。我们甚至使用我们自己的 DI ( http://www.expojo.com ) 和 Wicket,一切都很时髦。
Spring 比 Wicket 更包罗万象。
Wicket 是一个 Java Web UI 框架。Spring 也有一个,以及用于持久性、远程处理、安全性、消息传递等的模块。
Spring 建立在依赖注入和 AOP 之上。检票口都没有。
我没有使用它,但它应该很简单。我不能说春天是更容易还是更难。
除了 Web 应用程序之外,您还可以在很多情况下使用 Spring。
您可以在 Wicket In Action 的免费第一章中了解使用 Wicket 的优势:http: //www.manning.com/dashorst/
简而言之,当您开发的应用程序相对复杂时,Wicket 是一个很棒的框架,您希望它是可维护的,能够扩展团队并利用重用。面向对象编程被证明是一种非常有用的 UI 编程范式,但不幸的是,大多数用于开发 Web 应用程序的 Java 框架,包括 Spring MVC,只支持一种非常程序化的编程模型,它们在其中标记 MVC 术语以使其听起来很酷(但事实上,由于它们支持的粒度是请求/响应往返而不是自包含的小部件,因此 MVC 确实具有误导性)。
Spring 的 DI 部分很棒,您可以轻松地与 Wicket 一起使用。
我同意到目前为止提供的答案。没有提到的是以下几点,这是 Wicket 专注于 Java 代码的 Web 应用程序开发方法的结果:-
我还没有遇到任何其他采用这种以 Java 为中心的方法的框架。我使用过的所有其他工具(Struts、Spring)都涉及 JSP 开发。
对我来说,Wicket 的一大优势是专注于 Java,以及丰富的开发环境工具(如 Eclipse)的可用性。此外,业务逻辑与应用程序的表示方面非常清晰地分离。
我喜欢 Wicket 的一些优点:
易于部署。
Spring 仅在页面级别为您提供 MVC 设计模式——确实是一个非常粗略的粒度级别。相比之下,Wicket 为您提供了单个组件级别的 MVC 设计模式(就像 Swing 为胖客户端编程提供的那样)。使用 Spring MVC,表单的所有数据对整个前端 servlet 都是全局的,因此信息隐藏、松散耦合或紧密内聚的机会并不多。使用 Wicket,您的显示逻辑可以更加模块化——由 componentA 管理的数据不需要对 componentB 的代码可见。
较小的粒度级别使得跨多个不同网页甚至跨 Web 应用程序重用显示代码变得更加容易。
此外,由于组件配置是在 Java 而不是 XML 中完成的,因此它们可以在运行时动态配置,从而获得更大的功能和灵活性(与大多数其他面向组件的框架相比,例如 ASP.NET Web表单或 Java Server Faces)。
One other advantage of Wicket over other popular java web frameworks is that it allows you to create modular and extensible web applications. This is particularly useful when you are designing a web based product, which you intend to extend by adding extra functionality and pages in the form of plugins at deploy time, and eliminating the impact on the core functionality/source of your product. Here is a very good article on it.