RFC: Extending the MVC Design Pattern

Question

I've been using the MVC pattern in my applications for years (with full separation of the controller from its views).

Having to implement several hundred views to represent a little over 100 model's for a potential contract, this time around I'd like to reduce the development time of my UI tasks and also add a few additional features (view decoration, etc).

I'm curious to find out if anyone has used or even implemented a design such as the one I'll explain bellow and if so, what were your pros and cons were.

Without getting into too much detail, I'm going to simply elaborate on an example of an API I have been juggling with in my head for a few days along with some explanations a bit later on, so here goes:

Model m = dao.getInstance(ID);  // ie: possibly fetch it from a database

VTextField text = new VTextField();  // simply 'extends' the Swing components

text.setModel(m);

Decorator deco = DecoratorFactory.getInstance();  // specific to a customer

text.setDecorator(deco);

Controller c = ControllerFactory.getInstance(m);

text.setController(c);

Validator v = ValidatorFactory.getInstance(m);  // get the current validator

c.setValidator(v, "validateText");

So in the example above, the idea is that I will have the same application for several clients. Although each have accepted the general usability, each want their branded L&F to it, some based on business rules (ie: a text field has errors, the background of text-field should be in yellow with red fonts... an other want the text in black and the background yellow with a red border).

What I was thinking was that on any event (on focus, loss focus, key typed, etc), the component would basically invoke the controller. In turn, the controller (through reflection) would invoke the validator. If validation passes, the controller simply updates the model. If validation fails, the controller does not update the model.

The controller would keep a state of all of this (viewing, editing, editing with error, etc) and would delegate to the decorator which would adjust the L&F of each component based on client demands.

This would avoid a ton of 'if/else' blocks directly in a single controller. The controller, validator and decorator knows which concrete instance to load based on which client is running the application. This way, I can separate the logic for each client and reuse when it is shared behavior.

The decorator doesn't overide the paintXXX() methods, but simply calls the 'setBackground(c)', 'setBorder(b)' and all of these setter methods already available in the Swing components. The reason I extend each component is simply to add the 'setModel(m)' and 'setController(c)' methods along with any framework logic I'll need. When the component is in 'view' mode, it usually doesn't paint the border and background and all that stuff (looks more like a traditional web page). When it is in 'edit' mode then it looks more like a Swing component.

When I design application UI's I usually stick to only a few major components (JTextField, JTextArea, JPanel, etc). So it wouldn't be too much work on that side.

I have not started to implement any of this stuff just yet, so if you know of existing libraries which does something similar, please point them out.

My only real issues I have at this time is how to handle cases where component depend on each other. For example, two text fields having an int value. If one field is odd then the other must also be odd and if one is even, then the other must be even. When the validation occurs, the validator would need the value of the other text field to properly validate... so I still have not ironed out that part.

Answer 1

Maybe the Model View ViewModel (MVVM) design pattern, an extension to MVC, is suitable for you. It allows seperation of concerns such that UI-designers can focus on their job without dealing with the business logic, i.e. they can focus on the various L&F, as you wanted.

Such frameworks (e.g. Microsoft's WPF and Silverlight) are very powerful and expressive. The ViewModel is an abstraction of the view with data binding between the view and the model. I'm sure you can implement your ideas with these concepts and avoid serious issues.

To get an overview of these frameworks and the power of MVVM, I suggest this hanselminutes podcast about MVVM.

Answer 2

This is a desktop UI, right?

This might be too far afield for you, but ages ago I came up with (out of necessity) a different way of programming UIs. I've implemented it when I needed it in languages C, Lisp, C++, Visual Basic, and C#. In the recent incarnations I called it dynamic dialogs, and it saves about an order of magnitude of code volume over MVC and other event-based patterns.

The basic idea is I need a domain-specific-language (DSL) to program the UI. For example, in Windows there is a resource-compiler (RC) language used to describe dialogs. It's a good DSL, but the problem with it is it's too "static". It lives outside the main programming language (MPL), and it doesn't have access to all the variables and control structure in the MPL. As a result, it has to be surrounded by a lot of MPL code to handle events, move data in and out of controls, show and hide controls, or gray them, etc. All that puffs up the code volume and makes it difficult to modify, like adding a control takes several different coding steps in different places. Tools can help with this, but removing a control also takes several coding steps you get no help with. What's more, if you want any dynamic content, such as whole groups of controls appearing/disappearing dynamically, or varying numbers of them, it can be done but is relatively complicated to program.

In this DSL, I write a function (with sub-functions that it calls) in the MPL to paint the UI at any given point in time. Then that function is executed under a control structure called differential execution which transforms the function into one for also doing incremental update, as well as erasing, of the UI. So I don't have to write code to make dynamic changes to the UI. I don't have to write code to move data in and out of controls. That's all buried in the dynamic dialog implementation layer. I don't have to write separate event handlers, or invent names for controls. The event-handling code is embedded right in the code that paints the UI. If I need the event-handling code to be separated from the paint code, it's simple enough to make it a separate function, but I don't have to.

It's a different pattern/paradigm (whatever you want to call it). If I want to keep separate responsibility for appearance, model, activities, I can, but very often I don't need to. It does save about an order of magnitude of coding effort (and bugs), and it "just works".

So I don't know if that's any use to you, but if you want to move beyond MVC, I understand completely.

Answer 3

I'm not really all that sure what your question really is, but if it's an “Am I on the right lines?” then it would seem so to me, yes. The pattern of calls and constructions is a lot like the patterns of beans created in a Spring-driven application, and Spring is well-known for promoting a lot of good practices and sensible patterns (except that Spring lets you do a lot more by automatically wiring things together).

The only thing to beware of is creating hyper-generalized “do-anything engines” where everything is driven by semantic business rules expressed in XML stored in a complex database looked up using an enterprise service bus that is configured by … Well, you get the picture. I've seen a number of projects that tried to allow people to have applications driven by descriptions not created by programmers but instead by some business unit, and they've never really worked out all that well (unless you're a gigantic three-letter global services company that wants to have even greater amounts of customer lock-in^[*]). So don't be afraid of writing code for specific clients; instead, think in terms of refactoring common parts when you find that several clients need the same thing.

---

^{[* There are quite a few such firms, really. I've worked with several, and their attitudes are almost totally interchangeable. ]}