What design patterns fit this code smell?

I have a PDF form that has 450 fields in it and I'm going to fill it out using data that is in my Database. Each field in the PDF has a unique name and I can do a mapping like:

switch (fieldname)
{
    case "Name":
        value = GetData(Name);
        break;  // Etc...
    case "Date":
        value = Date();
        break;
    default:
        value = "";
        break;
}

Now it seems like this is going to get very complex fast having 450 branches and if other documents get added it could grow massively. What are the potential patterns that are available to solve this kind of problem? Essentially I want to bind the PDF fields to the Database fields.

* EDIT * So lets just say that I have a giant switch statement ~450 branches, that routes PDF field names like 'Name' 'Address' 'Phone' to the correct database query for execution. What other ways can I solve this other than switching on the field names when the field names are variable depending on which document was selected by the end user.

* FINAL EDIT * I thought about it for a day and came up with solution thanks to all the suggestions. I have a function called GetElement(). It takes the PDF field name as a parameter and executes a stored procedure that returns the database column and another procedure name as a map. Then using some dynamic SQL I pass the procedure name and column i'm looking for and return the results. Hard to pick the right answer here but I'll give credit to the one that pushed me the closest.开发者_JAVA技巧

From what little I know about your overall problem, it seems it would be easiest to store the field name along with the value in the DB. It's a simple name-value pair looping structure then, and you don't hard code name strings in your code that way either. More generic? Hope this helps.

I think you're trying to implement a Object-Property-Value system, the object here is a document which has various properties... having different values in different instances.

It's a very common model but best to be persisted in a storage other than a conventional RDBMS, maybe an xml database.

More than a design pattern I would go for a simpler approach, correct me if I made wrong assumptions:

• You have different types of documents, each one with a different mapping.
• During the application user can select any of those documents
• The mapping of a document can change and new documents can be added

One option would be to have a series of maps (with key,value pairs), that hold the configuration of the document.

The maps would initialized when the application is started from some configuration files (some properties or xml files), and the maps cached so you don't have to recreate them all the time.

When you process a document only have to choose the right map object and do a loop: foreach($field in $document): $field['value'] = getData(pdfMap.getValue($field));

If you need to change or add some configuration, just change the mapping files and restart the application (or update the map if you don't want to have to restart)

As a structured Document I think Visitor will be your best choice.

Can you not return all 450 data items from the database using a SELECT and then index into this using fieldname? Which language are you using?

eg

datarow dr = GetAllData();
foreach field in document {
  field.value = dr[field.Name];
};

You create your database table with same name as the pdf field name. You can then use this one to one mapping to fill values in you pdf file. I assume that all you set in you pdf are strings.

Another way: If datatype is of concern, you will need a field->datatype mapping somewhere (say an ENUM in java). Then create one function called getValue(fieldName) which calls getString(fieldName) or getDate(fieldName) or getCurrency(fieldName) based on the data type.

Your switch case for a data type will be 5-10 at max.