Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a control scheme that will support this with minimal disruption to the users when this occurs.
How should i support this in my final design documents.I have used MVC pattern in my client implementation.What are the main points which should be included in design doc,regarding the avove quote Kindly comment VikasSood
Hi Vikas, I think you need to consider what changes could happen, and what impact these changes would have on your program. So what would happen if a column was added? Will your screen(s) attempt to display it? What about column name changes? Will your searches still work? Or even worse - columns being reorderd! It could happen - how much recoding would be needed? Any? And if the system needed more data for a booking (for example with FBNS, if they decided that they needed to know whether the booking was Business class/Economy class or Adult/Child) how extensible is your design to handle the extra fields necessary? Would it require a complete redisign of some screens? If so, what happens to the poor user who now has to learn new screen formats? There are many more changes that could happen in real life, but I think trying to cater for them would be impossible - the ones I mentioned are the ones that I think we should be able to handle without too much problem. Regards, Andrew
I hope, the requirements indirectly says, MVC is must. As MVC is very flexible, future extensions is very easy to implement. Means, if datamodel changes, we need not change view, or controller. This is what I understood. Any comments? Regards, Ganapathy.
author and jackaroo
Hi Ganapathy, Yes, the model can hide the implementation of the datamodel from the end user. So a change to the database schema could be hidden from the view(s) which display it. Or a change to the database type (for example currently flatfile, could become relational database) is likewise hidden from the view(s). This is subset of one of the benefits of MVC: that each portion of the MVC is only doing one job. So the model is only concerned with providing access to the data source(s) - the model does not have to concern itself with how the data will be displayed. The view(s) are only concerned with displaying the data - they dont care about how to access the data. Another benefit of the MVC is that you can have more than one view for any given model, So one view can be designed for an application that runs on a local PC (as our applications do), another view can be designed for a web interface, another view can be designed for a WAP interface etc. All these views can be connected to the one model. Regards, Andrew
Joined: Mar 26, 2003
Hi Andrew, You are right. Thankyou verymuch. So I have some light to fine grain my client design. Regards, Ganapathy.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com