views:

161

answers:

1

Background: I am an intermediate web app developer working on the .Net Platform. Most of my work has been defined pretty well for me by my peers or superiors and I have no problem following instructions and getting the job done.

The task at hand: I was recently asked by an old friend to redo his web app from scratch. His app is extremely antiquated and he is getting overwhelmed by it breaking all the time. The app in question is an inventory / CRM application and currently each customer requires a new install of the app (usually accomplished by deploying it on a different domain on the same server and pointing to a new database).

Currently if any client wants any modifications to the forms such as additional fields, new features, etc my friend goes in and manually adds those fields to the forms, scripts, database etc. As a result all installs of this application are unique. There is no one singular source repository and no one single version of this app. Generally new features are overtime rolled into the other sites, but still this is done on an individual site by site basis.

I will be approaching this on a very modular basis. Initially I will be coding a module that will query an external web service for some data, display and store it, and periodically update it automatically. The next module will likely be for storing and displaying inventory data. This way I want to over time duplicate the current feature set of his app 100% but do it incrementally.

The Million Dollar Questions

  1. I want to make the app have user configurable form fields. The user should be able to go to an admin page, create a new forms page of a certain category, and then specify what fields he wants in there. He could say 'create a new text field called Item # and make it a requirement" and that will get stored somewhere. All forms will be dynamically rendered to screen based on what the user has configured. Is this a good way to go about the problem of having no idea what a customer could want in a form? and thus be able to store and display form data of any sort ? What sort of design pattern should I follow here?

    I am familiar with asp.net and the .net framework in general and have decent knowledge of javascript, html, silverlight, jquery, c# etc etc. I can work my way around web apps in a good way, but I am not sure what sort of framework or tech I should use to accomplish this task. Would ASP.net 3.5 webforms be the way to go? or should I look into ASP.NET MVC? Do I use jquery and ajax for complete decoupling of frontend and backend ? or will a normal asp.net page with some spattering of ajax thrown in working with a codebehind be the order of the day?

Just looking for general advice before I start.

I am currently thinking of using ASP.NET 3.5 webforms, jquery for clientside animation, ui, manipulation and data validation, and sqlserver + a .net or wcf webservice for backend.

Your advice is much appreciated as always.

+2  A: 

I've recently implemented a white-label ecommerce system for an insurance company that allowed each partner to choose their own set of input fields, screens, and order the flow of the application to suit their individual needs.

Although it wasn't rocket science, it added complexity and increased development time.

Consider the user configuration aspect very carefully In hindsight both my client and their clients in turn, would have been happy with a more rigid system.

As for the tech side of your question, I developed my project in VS2005, using asp.net webforms and webservices with a SQLserver back end, so the stack that you're looking at is definitely capable of delivering a working product. ASP.net MVC will almost certainly help as far as testability goes.

The biggest thing I would change now if I was going to start again would be to replace the intermediate webservices with message based services using nServiceBus, MassTransit or the like. While the webservices worked fine, message based communication should be quicker and more reliable.

Finally, before you start to code, make sure that you understand the current system's functionality inside and out. If the new system doesn't do something that the old system did, it will be pretty obvious to the end users straight away.

JustABitOfCode
how did you manage the "allowed each partner to choose their own set of input fields, screens, and order the flow of the application to suit their individual needs" part ?
Abdullah Ahmed
JustABitOfCode