API / Apache Wicket Interview questions
What is the difference between Wicket's component-oriented approach and Spring MVC's request-oriented approach?
The two frameworks model a web application around fundamentally different units of abstraction, which shows up in how a developer thinks about and structures nearly every feature.
| Wicket (component-oriented) | Spring MVC (request-oriented) |
| Unit of work: a stateful Java component object | Unit of work: a single request mapped to a controller method |
| State naturally persists across requests via the session | Typically stateless; state must be explicitly managed (session, tokens, database) |
| View is HTML bound to components via wicket:id | View is a template engine (Thymeleaf, JSP) rendered from a model map |
| Event handling: methods on component objects (onClick, onSubmit) | Event handling: one method per URL/HTTP-verb combination |
Neither model is universally "better" — Spring MVC's request-oriented style maps naturally onto REST APIs and maximally stateless, horizontally scalable services, while Wicket's component-oriented style trades some of that natural statelessness for a programming model that feels closer to writing a desktop GUI, which many developers find faster for building complex, stateful, form-heavy admin and enterprise interfaces.
What is the basic unit of work in Wicket's component-oriented model?
Why does Spring MVC's request-oriented style map naturally onto REST APIs?
More Related questions...
