Domain Models, Value Models, Swing Models

The fact is that blogging requires time. And if you're short of time then you don't blog well. You don't explain yourself. You don't get understood. And, since blogging is about explaining yourself, then you fail as a blogger.

That simple. That difficult.

And I think that's what has happened with my latest posts. Someone has warned me about it. Thanks for that. If it ever happens again, if I ever don't explain myself, then just ask. Please warn me about this. After all this is an interactive place. Don't be afraid to criticize or just complain! That's part of being interactive! ;-)

So I'm trying to connect the model to the bus. The idea is that whenever the model changes then events are generated and sent through topics in the bus to the view (that is responsible for painting them).

And this, although easy to explain in a few lines of blogging, is quite difficult to do in practice. Before rushing into the code I like doing some research. After all, that's the fun part of this! So please let me explain what I'm looking at, let me share that with you, just in case you want to add any idea!

Models: domain models, value models, Swing models

So, how many kinds of models are there? What do we mean by model? What's the "model" in the "Model-View-Controller" paradigm? What is a domain model? What a value model? How do Swing models (DocumentModel, ButtonModel and ListModel) relate to those? Why is Laura Ponte such a great model? (Oh, well, just because she's galician too? :-D )

Most of these questions are answered at the Swing Data Binding Framework by Karsten Lentzsch (well, Karsten doesn't talk about Laura Ponte, sadly ;-) ).

To be honest, Karsten's binding framework is the most interesting framework I've seen around for handling the model in a Swing application. Well, in fact is the only framework I know of for handling the model. Or do you know of any other out there?

Let me explain what I understand of it (and what I don't) and why this binding framework (that has been around for some time) is so interesting to me.

Domain models

(Many different definitions here, I'll try to explain my preferred one. I know there're different versions and definitions, but the following one is good enough for the purpose of this blog. I wouldn't like to discuss on this ;-) ).

Domain (object) models represent a conceptual vision of a system. The types of objects your software will be dealing with. The objects you design to deal with a business problem. Class diagrams or entity-relationship (ER) database diagrams are usually good enough to visualize domain models.

Of course, you want your domain models to be independent of the user interface. Domain models usually live in the business tier, whereas the views live in the presentation tier. And even when your application is not multi-tiered, you still want to separate them. To reuse your domain in another applications (or to exploit your domain model from different user-interfaces, such as a command line and a GUI).

For an example of a domain model you can see this image taken from this article at The Server Side.

As Karsten's explains in his article, Domain models can be built with plain Java Beans (Plain Old Java Objects or POJOS). I have to agree. Java Beans is the easiest way to do it. Having a Domain Model designed as a set of POJOs is simple, is serializable (can be persisted to the disk or to an object oriented database) and, if you use bound properties, you can have Observers listen for changes on the domain model. (And that's exactly what I want to do with an event bus, for instance).

But as Karsten's nicely explains in his article, it's probably not a good idea to make your view depend directly on your domain model. (That's what he calls "Direct Adapters", the reasons why this is not a good idea are explained in slide # 43 in his article).

A similar thing happens in J2EE applications. Usually in J2EE applications you make your domain object model persistent using Entity Beans, DAOs, JDO, Hibernate or a mix of those. The "conceptual vision of the system", the domain model, can then be persisted in a database. But when building J2EE applications you don't really want to make your view depend directly on your domain model. You prefer to use the Transfer Object Core J2EE Pattern in your servlets and JSPs. (If you're not familiar to Transfer Objects you can think of these as a small photograph of a part of your model). You also want to use View Helpers, and different other J2EE patterns in your view.

Value Models

So how to avoid the problem of making your view directly depend on your domain model?

Well, of course, by using an indirection. Make your view depend on something, say Value Model, and then make that (the Value Model) depend on your domain model. You've got the indirection. There's no (direct) dependency. Problem solved. This Value Model is explained in slide #44 of Karsten's article.

And that's the way a (nice) J2EE application works too. Make your views depend on your transfer objects, and make these be a (partial) copy of your domain model. Make your views depend on business delegates, but not on all the internals of your business tier.

Introducing indirections between two parts of your software makes dependencies between these controllable. Allows you to build a single point of contact, a logical frontier between tiers. Keeping the indirection under control means keeping the dependency under control.

If this indirection layer is correctly built then things are easier to maintain. What is interesting about Karsten's binding system is that this indirection layer seems to be correctly built. He uses a "universal model" (ValueModel) to separate the view from the domain model (see slice #47 for details on the ValueModel). So the view has to deal with a single type of objects: ValueModels. And not with the specifics of the domain model you're building. Views become reusable. Views become isolated from the domain model. And this simple concept makes things easier when building Swing applications: the domain model is focused in the business problem and the view is focused in correctly handling ValueModels, whatever they contain.

From domain to value models (to SwingModels)

So how to transform domain models to value models while keeping them in sync? As Karsten's suggests: by using BeanAdapters and PropertyAdapters (slide #52). These "adapters" listen the domain model for PropertyChanges. Whenever a property changes in the domain model the change is automagically transformed into a change in the ValueModel, and viceversa. Easy to do. Reflection as needed. The powerful java.beans.\* package into action.

There're several issues with this approach, namely avoiding syncing before the user presses an "OK" button, or handling lists and table models. Karsten keeps on explaining these issues in the following slides. Check his article for further details on these.

Karsten explains as well how to make different SwingModels use ValueModels. There're adapters for these. Again check his article for further details.

From domain to value models: by bus??

So why talking about all these models here? How do they relate to an event bus?

Well, if you go take a look at Karsten's article, at slide #54, you'll see something like this:


private void initComponents() {
  Album album = getEditedAlbum();  // 1
  ValueModel aValueModel =
    new PropertyAdapter( album, "classical" ); // 2
  JCheckBox classicalBox = new JCheckBox();
  classicalBox.setModel( 
     new ToggleButtonAdapter( aValueModel ) ); // 3

So what this basically says is that in order to initialize the views of your components you have to get a reference to the domain model ((1) Album here) and then build a ValueModel from it (2) and then build your GUI with the ValueModel (3).

Note that your GUI components (classicalBox) need only a reference to the ValueModel, and may be completely isolated from the domain model. What I mean is that you don't need your domain model to compile your GUI. You could refactor the code above and remove completely the "Album" class by hiding it in another class. By using some sort of ValueModel factory or something.

What I really mean is that you could do something like this:

This is, make your domain model notify changes using the bus. Let me try to be more specific: instead of writing


ValueModel aValueModel = new PropertyAdapter( album, "classical" );

(which means: create a new ValueModel that is notified whenever the property "classical" in "album" changes) use the bus to rewrite the view as:

// Create a new value model
ValueModel aValueModel = new ValueModel();
// That is notified of PropertyChangeEvents whenever
// an event is received through the "album.classical" topic
bus.addEventListener( aValueModel, "album.classical" );

and rewrite the domain model as:
// Get a reference to an Album in your domain model
Album album = ...
// Make the "album" bean send PropertyChange events when
// properties change. 
// When the "setClassical()" method is invoked on the Album bean
// then a PropertyChangeEvent will be sent through the
// "album.classical" topic in the bus
bus.addEventSource( album, "album" );

So you completely isolate your view from your domain model. You can make them change independently. You don't need domain models to compile your GUI (just ValueModels).

So that's what I'm investigating now

So that's why I've been writing about Java Beans and PropertyChangeEvents and PropertyChangeSupport lately. I am trying to build a suitable domain model using just plain JavaBeans. Plain POJOs.

And I will like to reuse Karsten's binding library to attach things to the bus. After all I think Karsten's binding library is the most comprehensive mechanism to tackle the model in Swing. Or is it not? Do you know of any other framework/library to do it? What do you think of this? Do you think it appropriate or just too complex?

Am I following the KISS principle? Or do you think this is too elaborate just to use models? (This is, shall I continue this or not?).

As always all feedback is greatly appreciated.

Have a good weekend,
Antonio

Comentarios:

Hi MC,

Thanks for your comments! (you've anticipated my next blog ;-) I'll try to explain it here now.)

I agree with you that Karsten's data binding fwk is more Presentation Model oriented.

What I find interesting about it is the mechanism to make the view aware of the domain model (the arrow from the domain model to the view). Making the domain model bound properties notify changes allows us to isolate the domain model from the rest of tiers easily (whether those events are sent through an event bus or not). This mechanism may be declared programmatically. And that's interesting to me ;-)

What I don't mind about Karsten's fwk is holding GUI state separately from the domain/application state. What I think is that different views may hold different GUI state while presenting the same domain model. Deciding a good place to keep this GUI state is what I'm trying to decide now (and this does matter me). Whether separated from the view (in a presenter/controller somewhere, more MVP oriented) or in the view tier itself (more PM oriented). As Martin Fowler says:

Deciding which of these alternatives is better seems mostly a matter of which poison your team prefers to drink. This decision would be strongly influenced by a decent framework that supports such synchronization.

What I don't like about Karsten's fwk is the view modifying the domain model directly (note that there's no arrow between the view and the domain model in my approach). I think the view has a too narrow "view" of the domain model to be allowed to modify it directly: those modifications should be grouped and coordinated in a controller, for instance. So, yes, as you say, I don't really like the Presentation Model approach (although Karsten's binding fwk seems solid enough to support it easily).

Finally yes, I'm thinking of this as a (public) brainstorming. So no problem for considering a new approach to things. I'm not afraid of failing to reach a good way to do things. Nor to present completely wrong ideas in public (and be aware of that ;-) ). I'm just investigating and trying to reach a decission (and this investigation is what I find interesting myself, making it public is just trying to see what all of you think and what all of you like and don't like about current approachs). I consider being in an inception phase (a la RUP); so all ideas, ways to do (and not do do) things, critics and complaints are greatly appreciated!

So thanks again!,

Antonio

Enviado por Antonio en octubre 22, 2005 a las 03:24 AM CEST #

Ok you lost me. I can admit it... Maybe I need more caffiene and to wake up before reading something like this! \*wanders off for coffee, falling asleep just outside his office\*

Enviado por Jeffrey Olson en octubre 24, 2005 a las 09:12 AM CEST #

Hi Jefrey,

I appreciate this. I admit this is too academic! ;-)

What I was trying to say is that the mechanisms used by Karsten's binding framework are interesting. And that Karsten's binding fwk could benefit from an event bus too.

I just don't have time to build a demo now. I will try to do my best and deliver some example later on.

Cheers,

Antonio

Enviado por Antonio en octubre 25, 2005 a las 03:11 AM CEST #

Yea I gathered that, once I get some spare time I'll read that link you had to Karsten's paper.

So are you slowly getting over your fwk phobia? I don't mean your using one, but your taking a good close look at them it seems! All first steps, right? ;)

Enviado por Jeffrey Olson en octubre 25, 2005 a las 08:28 AM CEST #

> So are you slowly getting over your fwk phobia?
> I don't mean your using one, but your taking a
> good close look at them it seems! All first
> steps, right? ;)

Yeah! :-D :-D (LOL)
Touché

Enviado por Antonio en octubre 25, 2005 a las 10:47 AM CEST #

I for one do not like annotations. The beauty of Java is its simplicity. Now I have to learn some guy's wacked out annotation logic that he thought was cool at the time. This looks somewhat like the C preprocessor to me; very useful, but sure creates a mess when you look at it 6 months later.

Enviado por Jeff Dillon en octubre 26, 2005 a las 12:16 PM CEST #

In an earlier posting you mentioned that you liked MVP's approach of storing GUI state once as opposed to twice in the Presentation Model approach. My understanding is that Karsten's data binding framework is geared towards using the Presentation Model -- I have never seen an example of it being used with MVP. What is your current thinking of MVP versus Presentation Model? Or perhaps you are thinking of yet another approach? If MVP, can you show a simple example of using Karsten's data binding framework with MVP.

Enviado por MC en octubre 26, 2005 a las 01:27 PM CEST #

The Spring Rich Client framework has extended Karsten's binding classes with additional abstractions. The ValueModel interface has been extended to include ValueModelWrapper interfaces. This allows for arguably more powerful extensions to Karsten's initial approach. <p/> For example, there is a BufferedValueModel implementation that encapsulates the original ValueModel, but adds methods for isModified(), commit(), and rollback(). When setValue() is invoked on the BufferedValueModel, the implementation stores this new value in a local property such as "bufferedState". When commit() is invoked, the BufferedValueModel simply invokes wrappedValueModel.setValue(bufferedState). If rollback() is invoked, it loses it sets bufferedState = null. <p/> There are also additional ValueModel wrappers that provide validation and type conversion. They leverage Karsten's work a lot, and because of this they don't want to break his original ValueModel contract. I think it would be more elegant to work with if the concept of a hierarchy of nested ValueModels was part of the ValueModel interface from the beginning. <p/> PS: I'm not sure that I see the value in your proposal of a complete abstraction of domain model from this intermediary value model delegate, but I will still be reading. :)

Enviado por Jim Cook en octubre 31, 2005 a las 03:35 PM CET #

Enviar un comentario:
Los comentarios han sido deshabilitados.
About

swinger

Search

Archives
« abril 2014
lunmarmiéjueviesábdom
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Hoy