Some Architectural/MVC Questions
Hi, I have some random questions/confirming suspicions about MVC and Services-layer.
To give little context for my questions; I'm creating a Swing desktop app. and I have DAO/Service/Domain layers (first time I'm using these layers). My application consists of a single JFrame, menubar, 3+ toolbars, lots of (modal) dialogs and a desktop-pane.
I have a singleton (I try to use it sparingly) Application-class, which basically contains only an ApplicationWindow and a ServiceManager. It also has a findService(Class clazz)-method, which finds a service by interface. There's also an ApplicationListener & ServiceListener for listening startup/shutdown.
Is it a good idea to create some sort of wrappers for Swing-components (like a Dialog-class) or simply use something like populated JPanels as a view? I've already created a one for the JDesktopPane ("Desktop"-class), though (mostly for the reason to have a nicer interface, better listeners and tile/cascade support). But I'm not sure if it'd be a good idea to create some "proper" View-interface/hierarchy for my MVC-views. Also, it's kindof blurry to me how the MVC-views relate to the Swing-components. I think that Swing-components are lower level than the MVC-view, but I just don't know if I should create some View-hierarchy or simply use Swing-components as views.
I don't really like the idea that methods like setButtonXXXEnabled are combined with the JPanel-interface but I'd prefer the simplicity of this approach - especially as the the MVC-views in my mind are very dumb (and delegate all work to controllers) and mainly just create Swing components.
I find it's very hard to have loose coupling between the view & controllers. Is it even worth something to think about? I think somesort of propertyChangeListener-based thingy might work. I just hate it how I currenlty have lots of ugly methods in various Views, like: setButtonXYZEnabled(), setRadioXYZSelected(), selectAllText() etc.
Currently, my views know very little about the Models, the Controller usually listens the Model and changes the view accordingly. I guess this is mostly due to the fact that even the Controllers don't usually know anything about the model since they operate to a Service-object instead. Does this make sense?
Also, does this look like a sensible Service-interface:
publicinterface ProfileServiceextends Service{
publicvoid showProfileCreateWizard();
publicvoid showProfiles();
publicvoid addListener(ProfileManagerListener listener);
publicvoid removeListener(ProfileManagerListener listener);
publicvoid add(Profile profile);
publicvoid delete(Profile profile);
publicvoid delete(String ID);
publicboolean exists(String ID);
publicint getProfileCount();
public Profile[] getProfiles();
}
The implementation of ProfileService creates and contains a ProfileManager and a ProfileDAO.
I think it might be a good idea to get rid of those showXXXX-methods in my Services-interfaces completely,
and have a something like dialogService.showDialog(String)? Or maybe even more generic, like viewService.showView(string)?
Or maybe I don't need to get rid of those completely, but their implementation currently looks like this:
publicvoid showProfiles(){
new ProfilesDialogController(this).showDialog();
}
And I think that's not very nice.
So lets say I make somekind of ViewService, which has a showView(String). I think the method could use
reflection to instantiate some views from some descriptions that have been already loaded (or are loaded lazily).
I guess it would make sense that the ViewService (or the underlying ViewFactory/Manager), would instantiate the Controller of the MVC?
Thanks for any thoughts
Message was edited by:
finalfrontier
