I’ve got some rather complex forms, that need to be configured by web designers.
I’ve been building some composite controls that appear to be doing the job.
The top level control is simply a container, and the sections of the form are contained within. SubControls implement common interfaces, (i.e. NeptuneAddressControl and MarsAddressControl implement IPlanetaryAddressControl)
Ultimately, everything needs to go into the same database.
Instead of exposing every field of the child controls as a prop in the parent, I’m thinking of implementing a Visitor that will span the control tree, and populate an Entity Object that can then write to the database.
Is this the right approach or am I way off base here?
I suppose the trade-off between using a map of properties and a visitor is the class implementing the visitor needs to know about all possible properties, whereas code that deals with a map can be independent of the contents of the form/DB.
With the visitor, you get the benefit of your code failing to compile when new sorts of data are added to the structure, so the compiler can help you out if you’re changing a complex structure.
The benefit with properties may lead to a smaller amount of code with no need to change the middle layer at all if new fields or controls are added later, depending on how generic you can make that code.
I suppose there are other alternatives, but I think the visitor approach makes sense. There are probably control-specific things you want to do like specialized validation that will be harder to code generically, so the task will be easier and should do a good job of prevent hidden errors due to changes in the control structure.