MVC
The Model View Controller design paradigm
dictates a level of abstraction between data, the user interface and the
interaction between them. This allows you to concentrate on making the best
design decisions in each areas without worrying too much about the impact that
the implementation of that decision will have on the rest of the
design.
When I design software I tend to split the job into three tasks: data modelling, user interface design and finally the "glue" to tie the two together. I've used this approach for a long time, but only recently (as in about two years ago) did I learn about MVC and start using that as my formal design method.
I'd heard of MVC for some time, especially when Java was introduced, as AWT and Swing are built around it, but I'd never bothered to investigate. Partly this was because I wasn't working as a software developer at the time (I was doing IT Management and didn't have much spare time) and partly because I only ever heard about it in conjunction with Java, which I was interested in but only because it was new and (so I thought at the time) highly innovative.
What led me to more fully investigate and understand MVC was when I started playing around with Squeak , which is a Smalltalk-80 implementation (although it's moved far beyond that). Squeak has a highly original user interface called Morphic, which is probably the only true object-oriented UI in the public domain (it grew out of research at Sun, originally belonging to a system called Self, which could be called a descendant of Smalltalk). However, Squeak also comes with a second UI - MVC.
I have a bit of a fascination with the history of modern computing (late '60s onward), so I started investigating Smalltalk and MVC and was amazed that this stuff had existed for 30 years. More importantly I was totally switched onto the importance of MVC in good design for object-oriented software development.
The MVC paradigm splits the design of software into three key areas: Model, the data structures and associated logic; View, the user interface; and, Controller, the code that ties together the Model and View. One of the nice things about MVC is that although the elements of the triad are related, you have the freedom to work on any two of them in isolation (the third element always needs the first two in order to tie everything together).
In my case I tend to model the data structures first (most of my work involves databases), then design the user interface. Once both of these designs are in place I start implementing the Controller code to glue them together. Working this way allows me to concentrate on one piece of the problem at a time, without being too concerned about the other bits until I need to be.
This is the real beauty of MVC: it allows you to work however you work best - there is no formal approach to follow, just the distinction of the three elements. For instance, when I'm designing the Model I'll typically be working on the database schema design at the same time, both elements which I'll then use in the UI and View design*. This allows me to take a broad view of the problem and see how the solution fits together, but doesn't distract me from the minutiae of the design for each area.
I've been using the MVC paradigm in earnest for the design of Workflow, where I've found it really comes into its own. I've designed Workflow to be highly modular to allow the flexibility of online updates to core assemblies (it's a .NET project) and to provide a rich API to allow others to write plug-ins to extend the product. In laying out this design I found that following the MVC "way" allowed me to concentrate my attention on the problem at hand, without worrying how it'll all fit together. However, once the low-level design for each aspect is produced I am able to see how to make it all fit together.
All-in-all I believe that MVC is one of the most valuable tools that anyone can use when designing (and implementing - MVC influences how you code the design as well as produce it) software. And the best bit is that it can be used regardless of your design tools, development environment or language.
*I strongly believe in evolutionary design and development. When I'm building a database application my design decisions for the schema are strongly influenced by and an influence on the design of the Model and its logic. Likewise, when I'm designing a user interface it is both influenced by and an influence (somewhat) on the Model (think in terms of presentation and usability). This practice can and should be extended to implementation as well. Most development methodologies assume that design is a sealed, separate process from coding - evolutionary development techniques discard this out-dated view. In evolutionary development you start off with a design and then subject it to the pressures of implementation, where it doesn't work you adapt it.
When I design software I tend to split the job into three tasks: data modelling, user interface design and finally the "glue" to tie the two together. I've used this approach for a long time, but only recently (as in about two years ago) did I learn about MVC and start using that as my formal design method.
I'd heard of MVC for some time, especially when Java was introduced, as AWT and Swing are built around it, but I'd never bothered to investigate. Partly this was because I wasn't working as a software developer at the time (I was doing IT Management and didn't have much spare time) and partly because I only ever heard about it in conjunction with Java, which I was interested in but only because it was new and (so I thought at the time) highly innovative.
What led me to more fully investigate and understand MVC was when I started playing around with Squeak , which is a Smalltalk-80 implementation (although it's moved far beyond that). Squeak has a highly original user interface called Morphic, which is probably the only true object-oriented UI in the public domain (it grew out of research at Sun, originally belonging to a system called Self, which could be called a descendant of Smalltalk). However, Squeak also comes with a second UI - MVC.
I have a bit of a fascination with the history of modern computing (late '60s onward), so I started investigating Smalltalk and MVC and was amazed that this stuff had existed for 30 years. More importantly I was totally switched onto the importance of MVC in good design for object-oriented software development.
The MVC paradigm splits the design of software into three key areas: Model, the data structures and associated logic; View, the user interface; and, Controller, the code that ties together the Model and View. One of the nice things about MVC is that although the elements of the triad are related, you have the freedom to work on any two of them in isolation (the third element always needs the first two in order to tie everything together).
In my case I tend to model the data structures first (most of my work involves databases), then design the user interface. Once both of these designs are in place I start implementing the Controller code to glue them together. Working this way allows me to concentrate on one piece of the problem at a time, without being too concerned about the other bits until I need to be.
This is the real beauty of MVC: it allows you to work however you work best - there is no formal approach to follow, just the distinction of the three elements. For instance, when I'm designing the Model I'll typically be working on the database schema design at the same time, both elements which I'll then use in the UI and View design*. This allows me to take a broad view of the problem and see how the solution fits together, but doesn't distract me from the minutiae of the design for each area.
I've been using the MVC paradigm in earnest for the design of Workflow, where I've found it really comes into its own. I've designed Workflow to be highly modular to allow the flexibility of online updates to core assemblies (it's a .NET project) and to provide a rich API to allow others to write plug-ins to extend the product. In laying out this design I found that following the MVC "way" allowed me to concentrate my attention on the problem at hand, without worrying how it'll all fit together. However, once the low-level design for each aspect is produced I am able to see how to make it all fit together.
All-in-all I believe that MVC is one of the most valuable tools that anyone can use when designing (and implementing - MVC influences how you code the design as well as produce it) software. And the best bit is that it can be used regardless of your design tools, development environment or language.
*I strongly believe in evolutionary design and development. When I'm building a database application my design decisions for the schema are strongly influenced by and an influence on the design of the Model and its logic. Likewise, when I'm designing a user interface it is both influenced by and an influence (somewhat) on the Model (think in terms of presentation and usability). This practice can and should be extended to implementation as well. Most development methodologies assume that design is a sealed, separate process from coding - evolutionary development techniques discard this out-dated view. In evolutionary development you start off with a design and then subject it to the pressures of implementation, where it doesn't work you adapt it.
Posted: Tue - February 3, 2004 at 12:22 PM
Quick Links
Calendar
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
Categories
Archives
Feedback
XML/RSS Feed
Credits
Statistics
Total entries in this blog:
Total entries in this category:
Published On: Jun 14, 2004 08:20 PM
Total entries in this category:
Published On: Jun 14, 2004 08:20 PM