NX: MVC in the GUI - unnecessary?

[Paul Tongyoo]

Hi everybody--
I've been looking over the rationale for the classes of my GUI layer and and have been having trouble saying with confidence that my class reponsibilties match the roles in the MVC pattern. This thought immediately brought another to mind, "Okay this is bad, because now i'm trying to get my classes to fit in with a pattern, instead of the other way around." So for help I went to go read up on the MVC pattern at java.sun.com, and I noticed that one of the main "forces" for its use is the necessity to represent data with multiple types of views.
It is my interpretation that this force is not a requirement of Sun's specs, and to a certain extent it could even be interpretted that they actually specify the contrary; they want only one view ("The client must display results in a JTable") and they don't plan on extending the system "much" ("the IT director does not plan for much reuse of the system" (I hate their use of the word "much", btw)).
Given the above, it will probably be my final design decision that the client only support one view of the data. So this means I shouldn't be using MVC, correct? Sure, I should work to separate business logic from view logic, etc. etc. but it's my understanding doing so is just adhering to good coding practices, and not really implementing the MVC pattern.
I'd greatly appreciate any thoughts on this; thanks in advance.
Regards,
Paul
[ November 10, 2003: Message edited by: Paul Tongyoo ]

[Rick Lu]

Hi Paul,

Given the above, it will probably be my final design decision that the client only support one view of the data. So this means I shouldn't be using MVC, correct? Sure, I should work to separate business logic from view logic, etc. etc. but it's my understanding doing so is just adhering to good coding practices, and not really implementing the MVC pattern.

I think MVC is good for most applications becuase it allow kind of loose relationshiop between the model and views, no matter how many view, even only one. Sun also addressed

Your user interface should be designed with the expectation of future functionality enhancements.

I suppose this implies MVC pattern. But of course, if you are uncomfortable with this pattern, just make your choose.
Regards, Rick

[Seid Myadiyev]

Hello Paul,
In my design, after user selects the room to book I ask the user for confirmation. My confirmation is in the form of a dialog box requesting the user to review the details of the room that was selected and continue with booking it. So on this confimation dialog box I have a JPanel which is one of the RoomView(s). For what my specs require of me this RoomView will be the only one I provide, but future enhancements may introduce more Views (future Views will simply need to implement the interface which I define).

[Jim Yingst]

I would agree with Paul that MVC isn't necessarily required. If you feel you've got a good logical design and it doesn't follow MVC exactly, that can be OK. However I would address this in decisions.txt - give a brief explanation as to why you preferred your way over MVC. One nice thing about MVC is that it's a reasonably well-known pattern, and other coders are apt to recognize it even if it isn't strictly necessary here. Another consideration though is that (in my instructions at least) it's suggested that the company eventually wants to offer this booking service over the web. So one possibility that comes to mind is that someone might want to replace your GUI with a JSP. The question then would be, how easily could they do this? How much of your code could be reused? This isn't a requirement, but it's something to consider at least.

[Philippe Maquet]

Hi Paul and Jim,
I am not at home, so I cannot easily find the thread I had in mind, but anyone interested in MVC should make a search on this forum with the keywords "MVC Eugene". Eugene Komonov wrote a few great posts on this subject.
I confess that I am still in trouble when I am trying to "think MVC" when my coding/design context is simple. It's always clear to me that View and Model must be separate. But I often hesitate about a separate Controller. In other words, I am sometimes tempted to write "MVC" this way : "M/VC", where the View is listening to its Model (till here it's normal ), but where the View "controls" itself. Example : a click on some button is user input. It's the Controller's job to handle it. It can do that by registering a callback on the button's actionPerformed. But most of the time, that "delegated" actionPerformed will consist in only one call to some method on the Model class, right ? So why not to code that call from the View directly ? Such example still confuses me a bit.
Anyway I think that in MVC, "M" and "V" are more important than "C". Ah, sacril�ge ! (french in the text).
I should reread all Eugene's posts !
In the meantime, any comment will be welcome ! Jim ?!
Best,
Phil.

[Jim Yingst]

Jim ?!
Personally I don't really care much about whether the View calls the Controller directly, or the Controller registers itself with the View. I did the former since it seemed a little simpler, but either way is OK. I figure if you change views you have to edit something, somewhere - as long as the connections are reasonably easy to find and understand, I'm happy. Just don't bury the connection between View and Controller in a method with a lot of other GUI or business logic code; that's my main concern.
It's always clear to me that View and Model must be separate. But I often hesitate about a separate Controller.
I think that AWT/Swing code tends to be long & complex enough already, so it's important to me to separate the busness logic out to a separate class. To me that's the biggest benefit to the V/C separation. But you can also abstract a lot of business logic out to another class, e.g. a DBAdapter facade. In which case maybe there's no longer much need to separate the remaining Controller functionality from the View. Or maybe that means that the DBAdapter is now your Controller? Hmmm, there are a lot of different ways to look at this. In general though I'd prefer to have somethign that looks like I'm following a standard design pattern, so I kept the View and Controller separate.

[Paul Tongyoo]

 

From Jim: Another consideration though is that (in my instructions at least) it's suggested that the company eventually wants to offer this booking service over the web. So one possibility that comes to mind is that someone might want to replace your GUI with a JSP.

This is a huge point that I completely overlooked; this is an explicit statement that Sun has plans to use a different View type to access the same data. Despite the IT director's lack of intention to reuse much of our code, I believe this sounds like strong support for an MVC architecture. Thanks Jim for bringing this to my attention.

From Philippe: But most of the time, that "delegated" actionPerformed will consist in only one call to some method on the Model class, right ? So why not to code that call from the View directly ? Such example still confuses me a bit.

Yes! I've run into the same situation multiple times, forcing myself to add extra code just to keep the MVC View-Passes-UserInput-to-Controller relationship intact. Let's say we take the shortcut of having the View call the Model correctly-- will Sun think we're breaching the MVC contract? This is one of those instances where I wonder if it'd be okay to not say I'm using an MVC architecture, but still imitate some of the MVC relationships in my code. But I wonder if Sun may think I tried to implement MVC without knowing about it, which would be bad.
Thank you everyone (Seid, Rick too)! Your thoughts have given me more ammunition in my case for/against MVC. Hope i don't hurt myself.

Regards,
Paul
[ November 10, 2003: Message edited by: Paul Tongyoo ]

[Philippe Maquet]

Hi Jim and Paul,
Thanks for your comments.

Paul:
Yes! I've run into the same situation multiple times, forcing myself to add extra code just to keep the MVC View-Passes-UserInput-to-Controller relationship intact. Let's say we take the shortcut of having the View call the Model correctly

Exactly that !

Jim:
In general though I'd prefer to have somethign that looks like I'm following a standard design pattern, so I kept the View and Controller separate.

It looks like the safest approach.
Best,
Phil

[Ken Krebs]

IMO, the UI for the application is so simple that a full MVC approach isn't necessary. If you had a complex menu/toolbar structure and/or a Multiple-Document-Interface, authentication/authorization requirements, or something else like that, then it would be a good idea to have a separate controller. The most important thing is that the Model should have no dependency on the View so that any sort of View may be substituted. It's perfectly OK in a simple application to let the View or it's delegates issue commands directly to the Model through it's API.
kktec
SCJP, SCWCD, SCJD