• Post Reply Bookmark Topic Watch Topic
  • New Topic

good desktop application architecture with JSR-295 beansbinding?  RSS feed

 
Janne Mattila
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm trying to come up with a decent desktop application architecture to be used with Netbeans and beansbinding, and it seems a bit difficult to come up with a clear design.

I would like to get a decent separation of concerns with presentation layer clearly separated from the core of the application. Application core would have 0 Swing dependencies.

I looked at some models in Desktop Java Live http://www.lulu.com/content/120769 and Martin Fowler's patterns. They seem nice but when I try to implement them in practice I run into some troubles.

1) Model-view-presenter:

http://www.martinfowler.com/eaaDev/SupervisingPresenter.html
http://www.martinfowler.com/eaaDev/uiArchs.html

In DJL's examples this means in practice that Swing-specific view implementation e.g. ShopCarViewImpl implements a non-Swing ShopCarView interface which has methods such as int getMaxPrice() that simply return the relevant state of the widgets.
Swing-less ShopCarPresenter has commitChanges() that gets called when ViewImpl detects it has been changed. Presenter then pulls view state using the ShopCarView interface and updates model accordingly.

OK, I could do that, but I don't see how I could benefit from / fit in JSR-295 here.

Fowler's version is a bit different but I don't see how beansbinding fits in there either.

2) Presentation model

Here we have a view and a PresentationModel class which holds the state of the view, in Swing-less form. I could have ShopCarPresentationModel which contains field int maxPrice. When max price is changed from UI, the view should modify PresentationModel accordingly. PresentationModel then updates the model when it determines it's called for.

I guess I could make this work. I am a bit unsure on what and how I should bind the Swing components to. Do I add the whole PresentationModel as a javabean into my form in Netbeans, and bind to it's methods? Should PresentationModel have getters/setters for all fields in the view (setMaxPrice) or does it contain a separate javabean for those and for binding (PresentationModel.carSearchParameters.maxPrice)? Should PresentationModel observe model changes, or should that be view's responsibility.

Also I'm curious if duplicating the view state and all fields in PresentationModel leads into much code and maintainability problems.

3) no pattern

Or, I could just forgot about these and bind the Swing UI components directly into my domain objects.

Any comments, anyone do this kind of work previously?
 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Janne,

without going into detail, I think I have understood your problem. Until now I only used beans binding in a few smaller applications basically because the beans binding support is very well integrated in NetBeans. Unfortunately for the same reason I didn't get involved enough into details to judge how well it supports a clear separation of concerns if you don't rely on the IDE support for it.

Although I can't come up with a full solution ad hoc, I'd like to tell you about an interesting thing I recently read in a book for the Seam framework which could probably be worth a try if the separation of concerns can't be completely solved with beans binding. Seam itself isn't a really good fit for a Swing best desktop application but perhaps it's possible for you to get some ideas there for an event handling mechanism which is a key concept in beans binding (at least for my understanding). Seam support a clean separation of event listeners and event sources by providing a few annotations to wire components without real Java code. I don't know how easy it would be to implement your own set of annotations which could internally use beans binding, but I guess it could be worth to think about the idea.

As I said beans binding maybe gives you all you need for a clean separation so it would be helpful to hear some answers from others who are more experienced with beans binding before looking at this Seam approach.

Marco


 
Dmitry Mamonov
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not experienced with SWING in ages, but here is my vision.

The application (data) model is not only thing you need to build UI.

I see three types of models needed, with corresponding controllers sure, to build UI app.

1. Application model - common data for all UI forms, i.e. text document in document editor application.

2. model inheriting UI - all data stored like:
class MyPanel extends JPanel {
String firstName; String lastName; etc.
boolean formFilledCorrectly = false;
}


3. model delegating to UI:
class MyTableModel extends TableModel {
List<MyDataBean> myDataList; etc.
}


4. Also, data is stored in concrete UI components, i.e. jTextField.getText().

BeansBinding will help you much to connect data of
models No2 and No3 to model No4.
But model No1 is a different one, I think it's bad idea to connect
application model to JTextField model directly. This way I should
pass data from Model No1 to Model No4 through models No2 and No3,
it is much more flexible. I can use same custom components
in completely different context if they are not locked onto root model (No1).

 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've used PropertyChangeListeners extensively in some applications to connect the "business" model to the GUI/Swing framework. It doesn't keep your business logic perfectly clean but an event based listener concept is probably the best idea to separate the layers and in fact this listener framework is not part of Swing but of the "beans" packages. On the other hand to my understanding this is basically the way the beans binding framework works internally so you don't have to wire every component by hand. I've found nothing wrong with this listener approach in general but of course you have to decide if you're willing to "pollute" your business classes with some small listener logic...

Marco
 
Janne Mattila
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does anyone actually use patterns like model-view-presenter and presentation model or are they just theory?
 
Rob Spoor
Sheriff
Posts: 20903
81
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you're using Swing you don't really have a choice but use the MVC pattern. JComboBox, JList, JScrollBar, JSlider, JSpinner, JTable, JTree - they all work with models. Event AbstractButton, and with that JButton, JCheckBox, JMenuItem, JRadioButton and some more classes, has a model.
 
Janne Mattila
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Prime wrote:If you're using Swing you don't really have a choice but use the MVC pattern. JComboBox, JList, JScrollBar, JSlider, JSpinner, JTable, JTree - they all work with models. Event AbstractButton, and with that JButton, JCheckBox, JMenuItem, JRadioButton and some more classes, has a model.


That's true. Use of Swing brings some kind of MVC into your application inherently. That's not enough for structuring your application though, as the M V and C are all very coupled and you cannot get clear separation of concerns just by using the MVC of Swing.

That's why at least the Desktop Java Live's http://www.lulu.com/content/120769 implements the patterns mentioned before to structure your whole application into layers. At some point there is a layer which does not know anything about Swing or the view specifics and is completely uncoupled from the Swing components. This is good for example for testability and clearness of the design. In the books implementation of PresentationModel, for example, there's no Swing dependencies at all. I believe that's the idea with Fowler's patterns too, they operate on larger "macro" scale than Swing's MVC. The M V and C layers inside swing are all contained either inside the Model or Model and Controller of the macro pattern (for example PresentationModel). Those do not reach into the Model of the macro pattern.

The MVC layers of Swing are considered separate from the "domain model" of the whole application. The "model" of Swing and "model layer" of your application are two separate things.

I don't think it's a good idea to bind a JTree or a JTable directly to your application domain model. I think there's a clear need to have a separate application layers which is independent of the view and the view technologies and does not even know if the view is implemented with Swing or SWT or AWT. http://www.martinfowler.com/eaaDev/SeparatedPresentation.html



 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd say that's it's worth to strictly separate Swing code from the rest of your application!

But I'm not sure what's your problem?!? I think beans binding is exactly made to allow this separation and doesn't require to write all the glue code by hand. I wouldn't focus too much on the precise implementation of a specific patterns. A framework like Swing already uses many patterns and it's likely to unnecessarily create a mess by mixing in too many additional patterns which don't really fit. Patterns are "advices" to solve specific groups of problems but you shouldn't force to include any pattern if it doesn't make much sense.

Marco
 
Janne Mattila
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marco Ehrentreich wrote:I'd say that's it's worth to strictly separate Swing code from the rest of your application!

But I'm not sure what's your problem?!? I think beans binding is exactly made to allow this separation and doesn't require to write all the glue code by hand. I wouldn't focus too much on the precise implementation of a specific patterns. A framework like Swing already uses many patterns and it's likely to unnecessarily create a mess by mixing in too many additional patterns which don't really fit. Patterns are "advices" to solve specific groups of problems but you shouldn't force to include any pattern if it doesn't make much sense.

Marco


Agreed on not using additional patterns just for the sake of it.

But take the aforementioned book "Desktop Java Live" as an example. I gather it's (and the autor Scott Delap) held in high regard, also in this forum, and it advocates the use of patterns such as PesentationModel to create a clear separation of concerns for your app. And I agree.

I don't see how just simply taking beansbinding into use would be "enough" for structuring my application. Where would I bind the Swing components to? I need some kind of structure in my application, so that the UI components are bound to something, be it PresentationModel or some other kind of layer of objects. What that "something" exactly is, is missing for me at the moment.

Are you suggesting I would bind directly to my domain model objects? Even if this could work in some simple cases, there's more complex UI functions that cannot be handled just by simple binding, hooking some components into some domain model object's getters and setters. Certainly there will be cases where beansbinding limits are reached and I need to do the binding manually. There's a need for a layer that does that kind of binding and separates my swing components from my application model / business logic services.

Have you implemented desktop applications using beansbinding? Where do you bind the Swing components to?
 
Rob Spoor
Sheriff
Posts: 20903
81
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Janne Mattila wrote:I don't think it's a good idea to bind a JTree or a JTable directly to your application domain model. I think there's a clear need to have a separate application layers which is independent of the view and the view technologies and does not even know if the view is implemented with Swing or SWT or AWT.

I completely agree.

However, you would never bind a JTree or JTable to your application domain model - you would bind a TreeModel or TableModel to your application domain model. And if you don't like that either (because you're committing yourself to Swing), you can always create a TreeModel / TableModel wrapper around your actual models. For instance, I've written a JDOMTreeModel and a FileTreeModel - one is backed by a JDOM Parent (so either a Document or Element), the other by a File. It would probably not be so hard to write a TreeModel for a custom tree based model, or write a TableModel for a custom grid based model.
 
Janne Mattila
Ranch Hand
Posts: 32
 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But take the aforementioned book "Desktop Java Live" as an example. I gather it's (and the autor Scott Delap) held in high regard, also in this forum, and it advocates the use of patterns such as PesentationModel to create a clear separation of concerns for your app. And I agree.

I absolutely agree to apply good design patterns where useful and appropriate. And I'm always striving for good OO design with clear separation of concerns. For this I can definitely understand your concerns. Believe me

From your last post, I'd say we can reduce this discussion basically to a discussion of whether it's good to wire some framework components directly to domain objects, right? I'd say it depends. In general I would try to separate all parts as good as possible. On the other hand this often means that you end up with lots of additional classes, facades or interfaces just to separate some layers more cleanly which in turn makes the application of course more complex. If you don't have framework at hand like the Seam example I told you about in my first post which does a lot of this wiring of layers behind the scenes with some "magic" like annotation processing etc., I don't see any chances how to completely separate the different layers without introducing additional components. So if you ask me, this whole thing is a trade-off between clean separation of concerns and added complexity for the wiring of objects and layers.

But be warned! As I told you I haven't used beans binding extensively enough to tell how powerful it really is and if it can help you to separate UI and business logic!

marco
 
Janne Mattila
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Prime wrote:
However, you would never bind a JTree or JTable to your application domain model - you would bind a TreeModel or TableModel to your application domain model. And if you don't like that either (because you're committing yourself to Swing), you can always create a TreeModel / TableModel wrapper around your actual models. For instance, I've written a JDOMTreeModel and a FileTreeModel - one is backed by a JDOM Parent (so either a Document or Element), the other by a File. It would probably not be so hard to write a TreeModel for a custom tree based model, or write a TableModel for a custom grid based model.


Is that the design you use when implementing apps? Swing Model objects are bound into application domain models (either directly or using wrappers)? There's never some other kind of layer (PresentationModel or whichever) between your swing Model and application model?

To be concrete, how would you bind this example in practise: you application "domain model" has object Bank which has method addCustomer(firstName, lastName, yearlySalary). Your Swing UI has 3 JTextFields for each parameter and "create new customer" JButton.
 
Janne Mattila
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marco Ehrentreich wrote:
From your last post, I'd say we can reduce this discussion basically to a discussion of whether it's good to wire some framework components directly to domain objects, right?


Yeah, that's at least part of my question. Other part is: if you don't wire directly to domain objects, what kind of structure should you have in between?

Marco Ehrentreich wrote:
I'd say it depends. In general I would try to separate all parts as good as possible. On the other hand this often means that you end up with lots of additional classes, facades or interfaces just to separate some layers more cleanly which in turn makes the application of course more complex. If you don't have framework at hand like the Seam example I told you about in my first post which does a lot of this wiring of layers behind the scenes with some "magic" like annotation processing etc., I don't see any chances how to completely separate the different layers without introducing additional components. So if you ask me, this whole thing is a trade-off between clean separation of concerns and added complexity for the wiring of objects and layers.


For sure adding a new layer such as PresentationModel will add a lot of code and classes. So indeed it's trade-off. One parameter affecting which side to choose is size of the application; smaller apps can do with less structure / layering.
 
Janne Mattila
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can find PresentationModel example from Scott's book at

http://www.java2s.com/Code/Java/Swing-Components/JGoodiesBindingPresentationModelPropertyChangeExample.htm

Although it's kind of hard to follow because a lot is done by from JGoodies binding framework.
 
Janne Mattila
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another source code example of PresentationModel-based implementation is at http://canoo.com/blog/wp-content/uploads/2008/09/pm.zip, from http://canoo.com/blog/2008/09/19/presentation-model-framework/
 
Janne Mattila
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since the discussion is maybe slightly "academic" at this point, I created a new spinoff thread with a question about a simple practical case: http://www.coderanch.com/t/450919/Swing-AWT-SWT-JFace/java/Using-JSR-beansbinding-where-do#2007544

Feel free to contribute there, too.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!