Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My team creates a lot of one-off web forms. Most of these forms just send an e-mail, and a few do a simple database write.

Right now, each form lives in its own separate solution in Visual Studio Team Foundation Server. That means we have close to 100 different form projects, which makes it difficult to maintain consistency. Each form is unique in that the fields are different, but all of them do pretty much the same thing.

I'm looking to condense these somehow, and I could really use some guidance.

  • Should I try to create one solution file with all of our form projects in it? There isn't a lot of plumbing code, although I could create a few helper classes to help with e-mail formatting and such. It would be very helpful to be able to share CSS, JavaScript, controls and images across projects.
  • Given that we're a Microsoft shop, are there any tangible benefits to going with something like MVC over Webforms for this specific scenario? I am sold on the concept of MVC as a whole, but would it help me pull together a 15-field data collection form more efficiently if all that form does is send an e-mail? The form that got me thinking about this had a good bit of logic built in to show and hide fields based on the user's responses and seems like it would have been less efficient to use MVC and jQuery.
share|improve this question

migrated from Jan 18 '11 at 14:13

This question came from our discussion, support, and feature requests site for professional programmers interested in conceptual questions about software development.

What was this migrated here from meta? Should be on SO. – Josh K Jan 18 '11 at 14:18
@Josh Stack Overflow is for questions directly related to specific problems in code. Program and workflow design is on-topic here. – user8 Jan 18 '11 at 14:20
@Mark: This doesn't sound very subjective, as in there would be n ideal "best practice" solution easily given. I'm not a MS guy so I have no idea what the complication is, however I would hazard a guess that this would be best answered in a non subjective manner. – Josh K Jan 18 '11 at 14:22
Agreed. This would get closed on SO. – Walter Jan 18 '11 at 14:22
It has already been asked on SO here – ChrisF Jan 18 '11 at 14:25

Re-factoring safely without tests is difficult and fraught with danger.

I would begin by:

  • Writing test case(s) that cover the various type of input into those forms and the expected output. It sounds like this wouldn't actually take too long as you feel most of these forms are identical in functionality, or close to it.

  • Run those test case(s) against the 100 or so forms (switch code coverage on to help you trace code pathways).

After that you're in a position to see what you can safely re-factor out, then you can (an example):

  • Run your code duplication detection tool (not sure what it's called in .NET, in Java we have CPD). Immediately Remove 13 identical forms. Now re-run the tests - Yay! They all pass except for form 11, OK, so we can't delete that yet.

  • Remove all local email formatting code and get all forms to call out to a common email processing module. Run tests, they all pass except for one, hhmmm OK.... UTF-8 characters, fix that in the generic module, run tests again, yay we're all good!

rinse and repeat.

share|improve this answer
+1 See Michael Feathers Working Effectively with Legacy Code for hints on how to approach refactoring. – Michael Brown Jan 18 '11 at 15:17
Ohhhh good reference - I do like that book. – Martijn Verburg Jan 18 '11 at 17:34

I'd suggest abstracting out the submission portion. Using Model/View/Controller, put the forms in the View, and have them use the same controller. This controller can either perform a generic action, like send an email to a default address, or divert the form data to a controller that can. That way all you have to do to create a new form is to create the form and direct the output to that controller. This archetecture could be contained in a single project, which would allow you to share CSS and javascript as you mentioned.

To handle formatting the emails, I would start by creating a generic formatter, say one that just list the form element names and values, as well as the other metdata type stuf like time submitted, etc. You could make this as fancy as you want. Then, if you really need more custom handling than that, add a factory. The factory would return a formatter interface. Then, within the factory, you could do a lookup for a formatter for that specific form or return the generic one if no specific one exists. This design would also make for easier unit testing of the cntroller, since you could easily supply a mock formatter for testing purposes.

Incidentally, I wouldn't put the email address as an argument from the form. If you need to send to multiple addresses I'd suggest having a lookup table that contains all the forms and the email to send them to. This could be implemented in XML or in code (I've seen both, though I'm not certain if either is better). This will help avoid spammers getting your email addresses from the form page.

share|improve this answer
Thanks for the reply. In this architecture, where would you handle formatting the e-mails that get sent? I would like to abstract this away, but I can't think of a way to do the formatting without creating a stringbuilder and dropping the fields in among the blocks of static text. This seems specific to each form. – Josh Earl Jan 18 '11 at 14:48
Also, any recommendations on handling form logic like populating a dropdown based on the selection in another dropdown? Is jQuery the only option if we went with the MVC route? – Josh Earl Jan 18 '11 at 14:50
@JoshEarl: I've edited in an idea for the formatter, but I can't make any suggestions regarding jQuery, etc. The web page side is not an area I am completely cormfortable making recommendations about. You may have to go with a full MVC design, one controller per page, if things are too complicated. As @Martijn said, unit testing will help you see exactly what your requirements are. My design assumes quite a lot of similiarity between the forms. – Michael K Jan 18 '11 at 15:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.