What pattern should I use?
-
Hi all: I have inherited a web application that's used for reporting. Each report has three main sections: Input section where the users select dates and other info, Summary screen where a summary of the data is shown, and a Detail screen where detailed data is shown. I don't think it makes sense to create a new Input, Summary, and Detail page when a user asks for a new report. Too much duplication! Is there a pattern I can use to simplify this? Let me know if you need more details. Thanks! Nick
-
Hi all: I have inherited a web application that's used for reporting. Each report has three main sections: Input section where the users select dates and other info, Summary screen where a summary of the data is shown, and a Detail screen where detailed data is shown. I don't think it makes sense to create a new Input, Summary, and Detail page when a user asks for a new report. Too much duplication! Is there a pattern I can use to simplify this? Let me know if you need more details. Thanks! Nick
First suggestion is, don't be afraid of "duplication". For one, Input, Summary, and Detail views, while they may all work with the same data, have distinct purposes, and will have distinct functionality that drive them. While you could probably merge all that functionality into a single glob, from a maintainability perspective...isolation of purpose (called separation of concerns and single responsibility in architect-speak) can offer you a lot in terms of long-term maintainability. My recommendation is this. Even if you need the Input, Summary, and Detail views to be represented as a single thing to the user...develop them as individual components that make use of a core, shared set of objects. Input should be a view component that encapsulates the logic required to display a form to the user and process that input. Summary should be a view component that takes the processed input and renders the summary. Detail should be a view component that takes the processed input and renders the full detailed report. Since each one is its own, isolated component, they can be maintained individually. That doesn't preclude them from being rendered into a larger composite view, so you still achieve what you want for the user (a single "page" from which a report can be queries, previewed, and rendered in full detail). If there is some duplication of code between the three components...that is ok. If you can centralize any common logic into a helper class that can be shared accross all three, great. If the logic is similar, but can't really be normalized, thats ok too. The key thing is that Input, Summary, and Detail are independant components that can be maintained, updated, and modified (i.e. with new functionality) independant of each other, which will improve your long term maintenance and product flexibility. Regardless of up-front costs...long term maintenance is by far the greatest cost of any project.
-
First suggestion is, don't be afraid of "duplication". For one, Input, Summary, and Detail views, while they may all work with the same data, have distinct purposes, and will have distinct functionality that drive them. While you could probably merge all that functionality into a single glob, from a maintainability perspective...isolation of purpose (called separation of concerns and single responsibility in architect-speak) can offer you a lot in terms of long-term maintainability. My recommendation is this. Even if you need the Input, Summary, and Detail views to be represented as a single thing to the user...develop them as individual components that make use of a core, shared set of objects. Input should be a view component that encapsulates the logic required to display a form to the user and process that input. Summary should be a view component that takes the processed input and renders the summary. Detail should be a view component that takes the processed input and renders the full detailed report. Since each one is its own, isolated component, they can be maintained individually. That doesn't preclude them from being rendered into a larger composite view, so you still achieve what you want for the user (a single "page" from which a report can be queries, previewed, and rendered in full detail). If there is some duplication of code between the three components...that is ok. If you can centralize any common logic into a helper class that can be shared accross all three, great. If the logic is similar, but can't really be normalized, thats ok too. The key thing is that Input, Summary, and Detail are independant components that can be maintained, updated, and modified (i.e. with new functionality) independant of each other, which will improve your long term maintenance and product flexibility. Regardless of up-front costs...long term maintenance is by far the greatest cost of any project.