I want to understand the pros and cons in generating dynamic web application controls.
The idea is to generate all the controls dynamically based on the database procedure output and populate the controls to a say a grid structure / independent controls.
I know that creating user controls and populating to layout is one option.
Say, if we don’t know what is the structure of controls the procedure is going to generate based on complex logic; what all should be considered in generating a layout structure?
Is what I am thinking of is not logical in web application sense?
Do I need to tackle the issue in a top down approach than a bottom up approach?
1
I think the question of whether you choose to tackle such a problem from the top down vs. bottom up is largely dependent on what design principles you seek to move towards.
The biggest concerns that I have from your proposed design is that the application tiers (Eg. Presentation/GUI, Middle Tier, Database, etc…) are muddied. There is nothing inherently wrong with a single tiered approach to application design, however if an Architectural Requirement or Assumption is provided that this must be a distributed multi-tier application then your design is already violating these principles.
If you are identifying the Database procedure as a seperate Component in a Component Oriented Architecture then you are now also introducing tight coupling. This however would not be tight coupling if your Components are all to be designed with vertical integration in mind. This is another architectural assumption you will need to check on.
Beyond that I have actually worked on such projects before that employed a similar design scheme and have seen the pros and cons of this design approach personally. In my honest opinion the Cons outweigh the Pros here. The pros here are that changes to layout and components on a screen become a schema change. If you anticipate that power users will have the ability to deeply customize their screens then it is an ideal model, however if this is not the case then it can be constraining, especially when new requirements dictate specific UI features.
Look into component based web frameworks like ASP.NET or JSF to see if these might better serve your needs without violating MVC or other architectural principles.
EDIT:
It seems that your requirements indeed dictate that users will have the ability to create their own screens and forms. In this case, the bottom up approach is best.
This can still work with a multi-tier architecture and MVC model, but it will be complicated. The following are some key points to keep in mind during your design process:
Decoupling
Keep your screen builder modules seperate from other domain business logic and data access. Keeping these decoupled allows the application to be more maintainable and scalable as features are added.
Model
The model in this case will be your application business logic, and data access as well as any domain model entities that you wish to declare. The screen builder model is seperate from this.
View (Screen Builder MVC and other Views)
The View will consist of the hard coded view pages as well as the entire Screen Builder module.
What does this mean?
Basically your View contains a completely sepereate self contained MVC design for user dynamic screens.
- Screen Builder Model: The data access to the stored procedure that returns the data on screen elements. This is also the domain model of the data returned.
- Screen Builder View: The code that generates the dynamic user generated view.
- Screen Builder Controller: The stored procedure, and other controller related tasks that mitigate between fetching and translating the model, and building the view for the user.
Controller
The controller in this case will be your web application framework controller.
The following model affords you a decoupled multi-tier approach by approaching the design of the dynamic form generation as a seperate MVC component operating inside of the web based MVC design of your overall application.
2