The problem
Data corresponding to the case has to be gathered from the UI, processed, and stored in the database. The data structure of this entity is unknown or at least partially known, since some fields are fixed, but depending on something I'm calling the case type which has metadata on the case, other fields may appear.The alternatives
The way I see it possible options can be grouped in the following categories:- Structured, strong typed, code generation based. Based on the case metadata residing in the case type I generate code, corresponding to: Business Entity datatype class, Database table create script (and execute it), and ASP.NET user control. Generation could take place right after metadata is declared/created.
- Unstructured, loosely typed, totally dynamic.. The case metadata is interpreted at runtime to create dynamically ASP.NET controls for the whole entity, load the entered data into an xml instance, and insert the xml into one table in the database, which has a text column to store the xml.
- Semistructured. This one is a mix of the former two. Based on the metadata code is generated for the ASP.NET user control, while the business entity common data is stored in properties, the non common data is stored in an xml type property (so the same class is used for all types of cases), and one text column is added to the Cases table in the database to store all the non common case fields.
After doing some thinking I started to implement the third, semistructured option. I guess the rationale for it would be something of the following form:
| Weight | Criteria | Structured | Semi Structured | Unstructured |
|---|---|---|---|---|
| 10 | Productivity | 1 | 3 | 3 |
| 10 | Performance | 3 | 2 | 1 |
| 7 | Maintainability | 1 | 2 | 3 |
| Totals | 47 | 64 | 61 | |
