Wicket Models
Here are just a few important things you should know about models:
Most components have a backing object of some sort (the string in our text field example) that is contained within the component's model. The generic type (i.e. String in TextField<String>) matches the type of the backing model (i.e. PropertyModel<String>).
These models are stored in the session and managed by Wicket after you create them – just like your components are. They are removed from the session when the page they are contained in is no longer in scope (for example, the user's session has expired, or the page is old and no longer needed).
Because they are stored in the session, you want them to hold the smallest amount of data possible. For instance, a model that retrieves a Person object from the database really doesn't need to hold a reference to the Person object between requests. Instead, if it held only the primary key value for that object, it could re-retrieve it from the database (or second-level cache) on each request, drastically reducing the amount of memory needed to store that page. This becomes especially important when dealing with models that load collections of data.
Models are always “detached” at the end of a request (the detach method is called), giving you the opportunity to nullify any fields within your model that aren't strictly necessary to retain between requests. This helps you save memory and disk space. Models that are passed to any Component's super constructor are automatically detached for you. Any models that you hold as references in private fields or passed as local variables to anonymous inner classes or are not otherwise passed to the Component super constructor should be detached by your own code (within the detach method of your component).
Models can be chained together where one model retrieves data from another model. A good example of this is the built-in PropertyModel class, which takes as its first constructor argument a model that wraps a POJO (which could itself be a LoadableDetachableModel), and then uses the second string argument to retrieve a property (or field) from the object contained within the first model.
Ideally, your Wicket forms and components will deal with models that directly use your domain objects. With Wicket, you don't generally need to create data transfer objects or simple POJOs as an intermediate layer. Instead, your models can deal directly with your domain objects, making it easier to pass these objects to your service layer.