Application Architecture for Dynamic Data Capture (loans application) RRS feed

  • Question

  • An enterprise loan application we are designing requires that the loan application data capture forms change periodically (e.g. every 6-12 months). This includes changing the UI and the data captured.  The current incarnation of the application has all the UI in the database (yes, the fields, their type, screen location, etc) and the data is stored as a highly generic name-value-pair in a table.  The users also require the ability to be able to look at any loan application data, at any point in time, displayed in the original format.

    By having this data driven approach, our automated unit testing is very difficult, we cannot leverage existing tools for UI development or for data object generation, and we compromise scalability, UI independance, established industry practises, etc.  However, changing the data capture forms and displaying data in its original form is relatively straight forward.

    Has anybody solved this problem in other ways that leverage a layered architecture?  Or any other way?


    Friday, December 1, 2006 9:19 PM

All replies

  • I'm not sure if I totally understand the requirements but it would seem to me that this might be a good placed to use infopath forms.  You could store the form in the database and use a foreign key to match the database record to the right form to display it.  This really doesn't address the testing issue but presumably an infopatch form would require less testing than your own UI code.
    Monday, December 4, 2006 4:20 AM