How to organize controllers/presenters in a large JavaFx 2.0 application?
For a project I've been working on a JavaFX 2.0 desktop application (a keytool UI). The way JavaFx2.0 works (in my project anyways), the UI event handling takes place in the JavaFX 2.0 UI classes itself (for example: onclicked() events or property change listeners).
Right now I use a static class with a method: getController(), which all UI classes use to access the one controller of the application (somehow it seemed messy to me to pass the controller on to all 50+ UI classes).
The problem is however that that one controller is getting very large! It has way too many methods (all business logic methods that need to be accessed by my UI classes). Even though it only passes the methods calls on to my model/service, there is still a lot of exceptions that need to be caught on controller level for handling them in the UI (show error messages etc).
Anyone know of a clean way to make this whole MVC/MVP pattern work better for my application without the UI / Controller / Model classes being directly depending on eachother? Maybe a different controller for each use case? But then how would I make it so that the right UI class gets the right Controller without directly knowing it? Maybe using an interface?
Answer
I don't really know Java FX, so you should take my answer with a grain of salt. I looked a bit at Java FX tutorials, but they all seem to be tiny examples with no architecture of any kind... MVC or other.
Maybe you should not try too hard to have a clean MVC pattern. It seems to me that each UI element is itself a MVC unit, e.g. a Label contains text (the model), its graphical representation (the view) and it handles events (the controller).
You might just be making your life more painful by trying to have a separate global controller.
You might however keep a separate model, which would be necessary for example if you are showing the content of a database (the model). However if you are doing something quite simple, just using the state of the UI as your model would be sufficient; keeping the data (model) separately in the program would just make you waste time synchronizing the data in the UI's and the data in the separate model. Data duplication is evil and should be avoided as much as possible.