Question

I have the following scenario (this fits into a larger mvc framework)

There is a large xml config which defines model types that are available to a specific feature of the system:

<object_type1_config>
    <type_id>1</type_id>
    <type_model>amazinTypeModel</type_model>
    <config_value1>blah</config_value1>
    <config_value2>blah blah</config_value2>
</object_type1_config>

In a controller, and based on certain request parameters I can decide which model to use at runtime and determine which template to render etc.

An additional complexity is that if certain values are not present in the config for that model type then a default set of values can be used. This default set of values will be used as default across all possble object types.

Problem is that the controller is getting filled with logic for parsing this config value to get parameters and then make decisions based on these parameters.

So it makes sense to move this out to another class but what is the best design pattern to use here since the controller actually still has to parse the config in order to get the model type first. Then it has to instatiate the model type and query it for values.

I cant see any way of decoupling things here

Was it helpful?

Solution

You could do something like this

class Controller {
    Parser parser;

    Model getModel() {
        return parser.parseModel(userInput);
    }

    Template getTemplate() {
        return parser.parseTemplate(userInput);
    }
}

And so on, where the parser already has a reference to the default config values (hardcoded in the Parser e.g. as a property files name, or passed in to its constructor). You can either set Parser via the constructor / setter, or if you're using Spring you can autowire it.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top