ASP.NET MVC solution to a forms application?

Question

Hello,

We're building a survey system and utilising ASP.NET MVC and wondered if anyone can offer suggestions on the architecture.

Here's the problem we're trying to solve. Essentially an agency sends out several surveys every year. They're very structured and not like SurveyMonkey style of surveys - they're actually applications of feedback. Much like a Visa Application there are lots of things they need to do and sometimes it takes them 2-3 weeks to fill it out.

They can upload files (proofs of purchase etc - PDF/JPG) and also multiple "items". Eg. Say for instance they've worked for McDonalds, there could be 20 different franchises, they build a list of locations they've worked. 3 weeks later there could be another 3 new locations and 2 may have closed down. So we need to ensure the forms are able to handle those situations.

The forms themselves (markup and data) change every year - I should mention that this for a taxation/finance/budget system.

We were thinking of using MVC, using Xml to store the data (temporarily), XSD to validate the data, XSL to transform the data to presentable markup (for them to fill out) and then once they "Submit" an application it gets stored into the DB in relevant areas.

When the user starts the application process, they can save the progress so far (we validate whatever they entred and ignore any they havent), save it as an Xml blob and store in the DB. When they're finally ready to submit it, then we do a full validation and upload the files and store them securely (it has their business proofs and accounting statements) and then run some workflows.

What I'm really concerned about is how to manage changing forms versions (a year later). How are form/application systems written these days? We have 2 months to pull this off and about 30 forms to deliver. So 30xXML, 30xXSD, 30xXSL.

Answer 1

This might be a case for integration with Windows Workflow Foundation, since you're talking about maintaining the state of a long-running workflow (completing the application).

If you could compartmentalize the various components of the application process, you could modify the workflow in future years by removing, rerouting, and/or modifying existing portions of the workflow.

That said, it sounds like you might have pretty tight time constraints. It might be worth a couple of hours' investigation into WF, but consider carefully whether introducing something new might jeopardize your deadline.

As for the XML, XSD, XSL route, I think it depends on your team's experience. Personally, I shy away from that and would store the data in one or more "pending applications" tables in a relational database. From there (of course, you could do this from XML, too), build up proper business objects and models to which my MVC views can bind. Field-level validation is performed with Enterprise Validation or Fluent Validation or the like, and final validation is performed by one or more validator classes that inspect all the constituent parts of the application.

To deal with possible changes, keep a clean separation between each of the 30 forms. You should be able to modify a given form next year without messing up others. Remember, you can always subclass or compose a model type if there are new requirements in future years, and you don't have to remove obsolete parts -- your new views just won't expose certain parts of the model.