is there only a View for each Controller and viceversa? MVC is about reusing the Model not the View. The link between View and Controller is notifications of user events. Thus there is a loose coupling. However we could make also a direct coupling from View to Controller without breaking the MVC goals. TIA
Hi Jose Traditionally there is one View for every Controller, and one Controller for every View. However there have been arguments for having more than one View per Controller. This is still possible, it is just not a traditionaly MVC. You will find there are many interpretations of what constitutes an MVC - so you can always pick the one that meets your needs Regards, Andrew
Like Andrew said, it can be any way you chose, and it is a personal preference. Personally I think it is cleaner for a one to one relationship between the view and the controller. But a string decoupling is encouraged. So to speak, if you can write the code such that you could swap out any part of the MVC without interupting the other areas, then you have a well decoupled solution. So if you had two views for one controller and there was strong coupling between them all that by changing one view made you change both the other view and the controller, then that wouldn't be a good design. Mark
Is MVC enforced in the SCJD assignment? It is not mentioned in the objectives. Could I use another pattern? MVC is applicable to a number of fields. Say we are talking about the SCJD assignment. Are the following points the essence of MVC? a) Business logic should not be placed in the View, but in the Model. b) The Views are not reusable. But there can be simultaneously several Views and some can be interchangable. c) The Model is reusable and can be shared among different V-C pairs.
author and jackaroo
Hi Jose I think you can use any pattern (or even no patterns) you like as long as you can justify why you chose to work the way you did. Personally I used HMVC. My models (3 of them) were shared by my views (5 of them). I agree with all your points about the MVC. I am not sure if you have encapsulated the essence of the MVC though (for example: your description does not explain why you would use it, or what the controller is for). But the points you mentioned would be the ones I would look at to see if someone was implementing MVC. Regards, Andrew
Whichever MVC you use , the benefits should be high decoupling, strong reusability and easy mantainability. In this thread MVC - How do you do it? note how we were trying to explore MVC boundaries. regards
Joined: Jul 03, 2001
Andrew, I agree. They are not the essence but the main goals when using MVC. Is there something missing? I tried to be specific to give the reasons to use MVC, rather than general desing goals as low coupling and high cohesion. Thomas, I had already bookmarked that thread . Thank you anyway. ________________________________________________________________________
I would like to compare MVC (*) with the three upper layers of the Layers pattern explained in Applying UML and Patterns. Larman says that coupling is from upper layers to lower ones, not from bottom to top. Tranlated into MVC, the main difference would be that the Controller is coupled to the Model, not loosely coupled as MVC implies. Another suggestion is for Model to collaborate with View. Instead, of using notifications a Facade in the GUI could receive the messages sent by the Model. This couples Model only to the Facade, not to the whole GUI. Anny comments please? For instance, does a Facade scenario make the View less indicated for MVC goals than using notification? Well, if the goals of a View is to be interchangeable but not reusable, I think is ok. What dou you think? (*) MVC for the arquitecture of an application not for constructing GUI widgets _______________________________________________________________________
My point is that reaching low coupling and reusabilty in all parts of MVC is loable, but maybe the effort is not worth it. If we are able to elicit the main benefits of MVC --what MVC buys you-- , we could know exactly the design elements we can trade off in order to get those benefits/goals. If the MVC goals are those I mentioned above I belive coupling from high layers to low one is not a problem. What dou you think? TIA
A word of warning before I go too far down this path: I did the SCJD for fun, and I put a lot into it that was completely unnecessary. A perfect example is my use of the HMVC pattern. Had I been doing one of the later assignments (URLyBird or Bodgitt & Scarper) with their warning against going beyond the requirements of the assignment I would certainly not have gone down this path. I certainly violated the KISS principle in a lot of my code.
I had the following models:
A model to provide information "about" the application (name, version number, author etc.). This was used in the "About box" (yet another case of going beyond the requirements ), and had the potential for handling internationalization and a few other niceties.
A model to handle all the modifiable options (IP address, port to connect to, DB location, window location and size ...) (do we sense a theme of me going beyond requirements )
A model to connect to the database itself (hey, something that was needed)
A model to provide contextual help (yes, I chose online help).
All the models were singletons. It was only really the database model that was shared by views and controllers - I had one view for "available flights", and another view for "booking a flight", which I felt gave me a much cleaner system, and an improved way of handling changes in the future (I would not do this if I were doing the current assignments though).
Since the models were singletons, both the Availability and the Booking controlers were able to connect easily to the same model. I also used the Observer pattern so that a change caused by the Booking controller would be reflected in the Availability view.
Totally confused yet ?
Joined: Jul 13, 2004
Thanks for your response.
Originally posted by Andrew Monkhouse: Had I been doing one of the later assignments (URLyBird or Bodgitt & Scarper) with their warning against going beyond the requirements of the assignment I would certainly not have gone down this path. I certainly violated the KISS principle in a lot of my code. ... (I would not do this if I were doing the current assignments though). ...
I think I probably agree. Yes more complex would be better in terms of possible future changes, but not for the assignment.
Originally posted by Andrew Monkhouse:
Totally confused yet ?
I'd be lying if I said that I understood it all fully... but I think I get the idea (well... enough of the idea to think it's a bit complex, and I think that if I try something similar there's a good chance of making it worse and losing marks)