Regardless of how user defined fields are stored, the object representation of those UDFs should be independent and support multiple back ends.

The first thing to start with is the classes used to manage and retrieve user defined fields. There are many things that you need to do:

  • Hold User Defined Field Metadata:
    • Hold a list of tables that have user defined fields:
      • Table Description
      • Table Name
      • Related Table
    • Hold a list of fields??in each table:
      • Display Names
      • Internal Column Names
      • Data Types (type, size, decimals)
      • Is the field required?
      • Is the field a drop-down?
      • Drop-down list object.
      • Is the drop-down a child of another drop-down?
      • Drop-down parent object
      • Default field value
      • Field display location
    • The ability to add fields
    • The ability to edit fields
    • The ability to delete fields
    • Drop-down lists:
      • Display Name
      • Table Name
      • Parent List
  • Hold User Defined Field Data
    • This is just the data held in each field

As I look at this list, the metadata is exactly what a relational database would let you store as table metadata. Nearly all relational database table metadata from various vendors allows for a comment, or description/name. The table names, column names, data types, required (not null), and default values are all stored in the RDBMS metadata tables. Additionally, relationships are stored through foreign keys, so that covers drop downs, parent/child relationships of drop-downs, etc. The biggest difference is that the nature??of the relationships is not stored in metadata. For example, how do you know that a foreign key is to a drop down. Secondly, although frameworks like Ruby on Rails and others read the metadata and build screens, we need the screens to be built dynamically at run-time.

Regardless of how the metadata is stored, the object model needs to hold the metadata so that the UDF data can be managed properly.

It is best if the metadata model classes are represented by interfaces so that you can have one way to access all of them even if the back ends are different. This allows you to change your back-end without changing the other components in the system. Also, there can be an abstract factory to generate the components so that the other layers (view and controller, typically) don't have to worry about how to create the back-end classes.

I'll continue later by fleshing out how these various classes and interfaces are implemented. I'll decide on the programming language as I go, but I'll probably start with Java, C#, or both.