Right now the Spring Framework reference documentation mentions data binding in two places:
The team discussed this theme, and we would like to update the recommendations here.
First, developers should consider immutable object design for web binding. In a modern application that could be records, or classes with a primary constructor. DataBinder supports both, including graphs of immutable objects.
Immutable design is the best line of defense because it explicitly declares the allowed inputs. In contrast to setters, which can lead to unexpected binding of properties. This is an inherently safe way to bind, and therefore it bound types can be either domain objects or dedicated objects for web binding.
Next, developers can consider a dedicated model object for web binding. This can be immutable or mutable objects with setters. This provides more flexibility and is also safe as the objects are designed expressly for data binding, and by design only allow the expected inputs, nothing more.
As a last resort, if developers must use objects not specifically designed for web binding (with potentially more properties), the will need to configure allowFields. Using disallowFields is not advised as this approach is fragile especially over time.
We should also better explain what part DataBinder#setDeclarativeBinding plays in all this; and that the allowed/disallowed fields configuration are in fact property paths, not field coordinates (with examples).
We are also considering reusing the content here to write a dedicated blog post to share our latest recommendations with the community.
We do not expect contributions on this issue as this requires a broader discussion within the team.
Right now the Spring Framework reference documentation mentions data binding in two places:
@InitBinderweb sectionThe team discussed this theme, and we would like to update the recommendations here.
First, developers should consider immutable object design for web binding. In a modern application that could be records, or classes with a primary constructor.
DataBindersupports both, including graphs of immutable objects.Immutable design is the best line of defense because it explicitly declares the allowed inputs. In contrast to setters, which can lead to unexpected binding of properties. This is an inherently safe way to bind, and therefore it bound types can be either domain objects or dedicated objects for web binding.
Next, developers can consider a dedicated model object for web binding. This can be immutable or mutable objects with setters. This provides more flexibility and is also safe as the objects are designed expressly for data binding, and by design only allow the expected inputs, nothing more.
As a last resort, if developers must use objects not specifically designed for web binding (with potentially more properties), the will need to configure
allowFields. UsingdisallowFieldsis not advised as this approach is fragile especially over time.We should also better explain what part
DataBinder#setDeclarativeBindingplays in all this; and that theallowed/disallowedfields configuration are in fact property paths, not field coordinates (with examples).We are also considering reusing the content here to write a dedicated blog post to share our latest recommendations with the community.
We do not expect contributions on this issue as this requires a broader discussion within the team.